Why do we need the Builder Pattern of GoF?

I've read the book of GoF about builder pattern again and again, the following are some of my notes:

• Director : It should be reused, and contain the algorithm(s) to build a Product, step by step. It uses the interface of Builder. It's who actually create.

• Builder : Just a interface. But it should be general enough to let almost any possible different ConcreteBuilder to build their Product.

• ConcreteBuilder : Should be able to build any logical parts of Product, and know how to assemble them.It contains a reference to Product. It's ConcreteBuilder who has the getProduct() method, Builder don't have getProduct() (abstract) method.

• Product : Complex object to be build. For every ConcreteBuilder, there is a corresponding Product. (If you want the example, please read design patterns by GoF)

• The client makes a ConcreteBuilder, then inject it into the Director, then the Director call its construct() method. Then the client get the Product by calling the ConcreteBuilder's getProduct().

It takes me a lot of effort to remember all these rules, but I have some question:

First:

If the Product is complex enough, it should be a bad design.

Second:

Ok, if you say it's not a bad design. So how can you design the Builder interface to satisfy any ConcreteProduct?

The only advantage of the Builder Pattern to me is related to the scope issue: since any ConcreteBuilder implement the Builder interface in their own scope, the client outside of the Builder don't know anything the ConcreteBuilder need to build its Product. Even better, since all the methods inside the ConcreteBuilder can share those variables without having to pass them through parameter of method, the methods should be easier to write and read. (From the book Clean Code, the more parameters a method has, the worse)

If I get something wrong, please reply, don't just downvote. I really want to know other advantages of Builder Pattern(of GoF, not Fluent Pattern).