Here's the internal details of the guts: BUILDALL has so far been sort of an interpreter for something called the "buildplan". When a class gets composed (usually what happens immediately when the parser sees the closing } of the class definition) all attributes are considered along with their defaults and requiredness and such and the buildplan is created as a step-by-step list, kind of like "take named argument 'foo', put it into attribute $!foo" and "take named argument 'bar' if exists, otherwise run the provided code, then stash it into $!bar".
Putting a BUILD into your class disables every attribute-related steps. You will have to do all the defaults and requiredness checks yourself. TWEAK on the other hand gets put in as the last step of the plan. The work lizmat just did on BUILDALL was to create an actual piece of code for every class that does what the interpreter would have done, but now that the code is actually code rather than a loop with a big switch statement, the dynamic optimizer can do much smarter things with it, for example inlining the body of any default value initialization code (like has $.bar = $!foo * 2). Maybe that helps clear up things a bit?
