Better naming pattern: SingletonAntipattern*.
The actor/CSP model makes each device a separate process, which can be hooked together with processing nodes works wonderfully.
You call it TheSecondCamera, duh.
For programmers who have not been through the process of evolving game design and engine requirements getting the balance of flexibility and productivity is tricky. Hoping the fact JC uses singletons does encourage them to be sprinkled more liberally than they already are!
It's things like this that turn a 'sure, we can make this game split-screen' into 'you didnt tell us you wanted split screen, that's gonna take a while'.
(Don't get me wrong, they are necessary)
For example, how would you go about implementing a connection pool without a singleton? Even if you pass it around everywhere, it's still a singleton, just explicit instead of implicit.
To your example of the connection pool, there is absolutely no reason that this has to be a singleton. You could have N connection pools, each with their own pool of connections, just as you could have N thread pools, or N memory heaps. This is not only possible but sometimes preferable, if different subcomponents need resource isolation (so that some connection-hungry component can't starve a component that needs reasonable responsiveness for the interface, for example).
Further, most of your code shouldn't even care about the connection pool. That's a level of coupling you generally do not need. Most code should care only about an actual connection, which could be passed in. Taking a direct dependency on the connection pool when not necessary increases pointless coupling and makes changes more expensive.