First, the new method normally takes parameters that match all my attributes.

As others have mentioned, the constructor can take any parameters you want to provide. Moose provides the mechanism, not the policy.

... why is it the caller's (the user of the object) business what my object's internal state is?

The constructor API is only the constructor API you declare. I have plenty of objects which take data provided to their constructors and then are effectively immutable. It's a nice pattern, when you can arrange your objects to behave in that fashion. As you say:

They will be used by the setup code to construct and arrange the various internal machinery of this instance, and may not be needed again ever.

... which matches my experience in many—but not all—objects.

... the framers of the system decided this was the normal thing to do, and the whole idea makes no sense to me.

I think you're overthinking it. People who create objects with accessors and mutators and constructor parameters for each and every attribute end up with slightly encapsulated structs and the concomitant risks. Moose allows that. Moose also allows people to create objects with neither accessors nor mutators and purely constructor parameters and various combinations of dependent attributes thereof. Where Moose expresses an opinion on how to design your objects, it offers a preference for declarative syntax and encapsulation. How far you take that encapsulation is up to you.

Is there a separate slot-access syntax that's not in the tutorials and manual?

In the sense of private, protected, or friend modifiers, no. Those don't really work in practice, especially in Perl. (I believe you need special hardware memory protection to make them robust. Then good luck writing a performant garbage collector.)