Private methods are completely invisible outside of a class, so they cannot participate in the public interface. Submethods can be called from outside a class just like ordinary methods. The only way that submethods are different from methods is that the dispatcher ignores them unless there's an exact match on the class (either because that's the class of the object in question, or because the class was requested as part of, say, a SUPER::.)

For instance, if you write a constructor such that it can be inherited, then you should declare it a method. But if there are implementation dependencies in your constructor that would make it a bad idea to inherit, then you should declare it a submethod. It's not a private method--you can still call it from outside the class. But any class deriving from your class had better arrange for its own constructor, unless some other class in the tree provides an inheritable constructor.

In particular, initialization routines that work on your particular set of attributes should submethods. It makes no sense to virtualize such a utility routine, because if you do hierarchical construction and destruction (as Perl 6 will), you'd just end up initializing the same attributes more than once if someone else uses your routine on their class that derives from your class. On the other hand, the routine needs to be callable from outside the class, or your child classes can't walk up the class tree to do hierarchical initialization.

On the gripping hand, classes with a standardized list of attributes can inherit a standard initialization routine that is metadata driven, and hence class independent. But it's probably slower than if you hard-wired it for your class. Submethods allow both implementation inheritance and implementation hiding under the same public interface.