Using a game class has a number of other potential advantages. Firstly, it can allow you to benefit from inheritance and polymorphism. If you're utilising an underlying framework, that framework might provide a Game class which can be extended, thereby handling much of the lower-level stuff. Certainly this can be handled using a number of separate systems, but there's certainly scope for conveniently handling timing values and calls to update the input system through a base class.
In the same way, you can benefit from polymorphism. In the Heron Framework, which I've developed and used for a number of years, there are multiple extensions to the game class that provide more specific functionality and, more importantly, there are different versions for different platforms. Once again, there are other ways to approach these issues but this is one convenient one.
There's also the possibility to consider scope for multiple 'games.' In Heron, there's a 'GameMode' class which provides the functionality of a game loop but is managed by a game. This effectively allows multiple 'Game'-type classes to be created, loaded, unloaded and run. In this manner separate components can be loaded separately and unloaded when not required, though this is usually handled in other ways. More often, I use this class to create a single game class in a portable library.
A final way in which multiple 'Games' might be employed are in tools. While not games, a number of the tools I have created employ Game classes to manage components that utilise the graphic device and may also employ the input system or content pipeline. In such cases it is beneficial to separate the game from the remainder of the application, and also sometimes necessary to create multiple games and run them simultaneously.
These are some of the reasons I, personally, choose to use game classes. Like rip-off, I also have an aversion to globals. That said, there are many other valid approaches to the problem, such as utilising a graph of systems and components.