To be honest, I can't rationalize the processor name—that was a decision by an individual developer, likely made to get around the fact that the MODX architecture was not built on what are by now well-established autoloading standards.
A lot of the class loading is done by the xPDO::loadClass() method, though the original intention of this was simply to be able to load platform specific classes within xPDO models. Again, this pre-dated modern PHP autoloading standards and the result is generally a mix of custom class loading via loadClass() and various include(_once)/require(_once) usages.
That said, this is absolutely one of the primary architectural goals for the next major release of MODX. We must adopt already accepted—and remain flexible enough to quickly adopt emerging—PHP standards that will allow MODX developers to make use of modern coding techniques, follow the sage advice at
PHP The Right Way, and avoid hours of learning proprietary APIs and packaging techniques in order to develop anything. Autoloading, logging, dependency management and other "core" features in the next major MODX release should reflect the same level of creative freedom for back-end developers it already strongly conveys to front-end developers. IMO, this milestone must be attained to gain enough momentum to reach critical mass in forging a sustainable MODX developer ecosystem.