The point is to have *some* consistent default ordering, which can be overridden by the user. zope.viewlet's default mechanism to sort on the registration name provides a form of consistent ordering (though not actually if two registrations with same name are involved; not sure whether that's possible). It isn't very good to allow it to be overridden by the user; you'd have to start coming up with wacky names. For that reason zope.viewlet *also* provides another base class WeightOrderedViewletManager, where you can put in a 'weight' attribute on your viewlets and have it sort by that. That takes care of user overriding of order, but suddenly it doesn't have consistent default behavior anymore (everything has weight 0 if you don't specify the weight). It also supplies the (underdocumented) option to override the 'sort' method to do your custom ordering. I think it's good to support this, which is where JW is coming from.
grok.order() and sort_components take care of consistent, user adjustable ordering, through an explicit directive. If you don't use the directive, ordering is still consistent, using class name and module name. You suggest we also should sort on viewlet registration name (and JW's code also suggests this). I don't understand: why would you *want* to sort by viewlet registration name at all? (note also that by default, the registration name and the class name will be the same). I'm not saying I have a better reason to sort by class name by the way, except that it's more generic. I'd *prefer* to always sort by definition order in the module, but unfortunately this is hard to accomplish, so we fall back on class name.
About inlining sort_components into the viewlet manager: grok.order and sort_components are not specific to viewlets, and are tested with an independent test suite. Inlining it would make testing harder. The intent of having this infrastructure is to allow its use for other sortable things as well besides viewlets in the future, such as menu items. Yes, if you'd put the registration name in there it *would* become viewlet specific, but you'll need to give a good reason why this is useful first.