Of course you can do that, but you'll never get Liferay to approve such a thing, and any real SCM will probably push back on it also.
Global class loader is the same sort of hack as a global variable - they both suffer from severe code smell. Sometimes they're necessary, but often times they are best avoided.
Putting into the global class loader, you always have to worry about dependencies; any dependencies you introduce must also be resolvable in the global class loader. Once you put a class in the global class loader, that often overrides what you have in the local class loader so sometimes you will have version issues to worry about. Sometimes when you make the dependency global, it has all kinds of transitive dependencies that must also be global, so you get into all kinds of trouble there, too.
For such a simple case as this, perhaps this is not an issue. From the SCM perspective, though, deploying something to global space is frowned upon. SCM would mandate that a global change requires a complete global test to ensure that the change is fully tested and approved before it can be promoted.
Finally, there's just the maintenance issues which can also work against you. A global class like this has no deployment support. On windows, you can't update globals while the app server is running, so the app server must be shut down to deploy an update because tomcat has the files locked and the OS won't allow the overwrite. On non windows, you may be able to overwrite while the app server is running but many will still use the old, loaded version until they are restarted.
Then you get folks who deploy both globally and a different version locally, and they wonder why they get results different than expected because they lose sight of the fact that they have some global class/jar which trumps whatever local code they're trying to use. This is the kind of scenario that drives everyone nuts (client gives war/jar to liferay to test, works fine there and close ticket, client mad at "works for me" response), mostly because the global guys have unexpected impacts to deployed apps.
Once the EXT is back, that would be the way to push something like this, but imagine the frustration trying to figure out what is going on if the class was previously manually put into the lib/ext directory and EXT doesn't take hold because some sort of class loading order issue? Who wants to take the time to diagnose that kind of nightmare and resolve it?
So yes, while it is possible to push like this, we will never tell you as much because it just comes with so much baggage.
Come meet me at the 2017 LSNA!
