Great article!

The whole idea of a "GameManager" can eventually lead to spaghetti code. If you can't answer the question "what is this class responsible for?" without adding an "and", it's probably better to rethink it.

Having a bunch of "managers" each for one specific system is better. Like InputManager, AudioManager, DatabaseManager, UI/ViewsManager, LocalizationManager, CombatManager, the list goes on.

The states can make calls to the managers to do something like "fade out screen to black". The manager will perform the action and fire a callback. The state can listen to that, and then transition to a different state.