An infinitely better example would be an static-inheritance class giving access to something like the graphics device. On one of my older projects, the "sprite" class is typically accessed very far down the call stack. From the entrypoint of the program, you have to go through a few layers of gamestate logic, then UI logic, then all the way at the bottom is the sprite class. The sprite class needs access the graphics device, or whatever class is handling the graphics device. Instead of passing down a reference to the graphics device down a dozen layers of call stack, the Sprite class would inherit from a static class that contains the graphics device.
This appears to be more a flaw of your overall design. Normally, the further down you go, the less you information you need - and the less things you have to pass on. Sure there is exceptions to this, but if you really need to acces the graphics device down so far that you have to pass it down several layers without using it, there is something horribly flawed in the first place. Your classes probably have too much responsilibity, aren't encapsulated well enough, etc... . I remember the same thing from one of my first projects, where I had to pass the DX9-device around EVERYWHERE. But this was, also, a design flaw per se and not a inconvieniente thing solved by inheriting from a class that grants access to a graphics device.
Seriously though, this inheritance-thingy is not much better than a global or singleton. In fact, it is even worse, because it create a relationship that has no purpose other than to save passing a parameter. Inheritance should always represent an "is a" relation. Whats that in your case? "sprite" is a "convienient static data container for a g.d."? That sounds about wrong.
I'll admit it's hacky as hell, but I'd rather have an ugly hack than restructure 10k lines of UI logic.
Well, you better would - otherwise you'll eventually reach a point where there is no back and forth, where the code overall becomes so ugly and hacked together that you can't develope it without insane effort, and where refactoring is virtuall impossible, forcing you to start over. But after all, thats up to you - just saying that the earlier you start to rely on hacks (namely things that you yourself call "hacky") the more messed up your code gets...
