The engine already uses many singletons. If someone used it, then they
should be familiar with some of them:
Unfamiliarity isn't the reason why singletons need to be avoided.
There are many good reasons why Singleton is necessary or unavoidable. Game frameworks often uses singletons because it is an unavoidable consequence of of having just a single stateful hardware. It makes no sense to ever want to control these hardwares with multiple instances of their respective handlers. The graphic surface is an external stateful hardware and accidentally initializing a second copy of the graphic subsystem is nothing short of disastrous, as now the two graphic subsystem will be fighting each other over who gets to draw and when, overwriting each other uncontrollably. Likewise with event queue system, they will be fighting over who gets the mouse events in nondeterministic fashion. When dealing with a stateful external hardware in which there is only one of them, singleton is unavoidable to prevent conflicts.
Another place where Singleton is sensible is with Cache managers. Caches are a special case. They should not really be considered a Singleton, even when they use all the same techniques as Singletons to stay alive and live forever. Caching services are transparent service, they aren't supposed to alter the behaviour of the program, so if you replace the cache service with a null cache, the program should still work, except that it only runs slower. The main reason why cache managers are exception to singleton though is because it doesn't make sense to shut down a cache service prior to shutting down the application itself because that will also discard the cached objects, which defeats the point of having it as a singleton.
Those are good reasons why these services are singletons. However, none of the good reasons to have singletons apply to the classes you have listed.
Because I will need them in very different places in my game, and shared access would be very handy.
Those aren't reasons for singletons. Those are reasons for globals. It is also a sign of poor design if you need to pass a lot of things around various systems. Having to pass things around indicates high coupling which can be prevented by good OO design.
Just from looking at the list of classes in your post that you think need to be Singletons, I can say that half of them really shouldn't be singletons and the other half seems like they shouldn't even be there in the first place. That you need to pass objects around seems to be due to the lack of proper encapsulation rather than actual good use cases for singletons.
Let's look at your classes bit by bit:
PlayerData (score, lives, ...)
LevelData (parameters per levels and level packs)
GameData (you may obtain some data from server to configure the game)
Just from the classes names, I would say that these classes smells like Anemic Domain Model antipattern. Anemic objects usually results in a lot of data that need to be passed around which increases coupling and makes the rest of the code cumbersome. Also, anemic class hides the fact that you are probably still thinking procedurally rather than using object orientation to encapsulate details.
IAP (for in purchases)
Ads (for showing ads)
Why do these classes need to be singletons? It seems to me that these should be short-lived classes, which should be brought up when they are needed and deconstructed when the user finishes the purchase or when the ads no longer need to be shown.
EntityComponentSystemManager (mananges entity creation and manipulation)
In other words, a constructor and a service layer? Why is this class with no clear boundaries nor purpose even there in the first place?
PlayerProgress (passed levels, stars)
Why is the player progress separate from the Player class? The Player class should know how to keep track of its own progress, if you want to implement progress tracking in a different class than the Player class for separation of responsibility, then PlayerProgress should be behind Player.
Box2dManager (manages the physics world)
I can't really comment any further on this one without knowing what this class actually does, but one thing is clear is that this class is poorly named.
Analytics (for collecting some analytics)
SocialConnection (Facebook and Twitter login, share, friend list, ...)
This seem to be the only classes where Singleton may be reasonable, because the social connection objects are not actually your objects. The social connections are just a shadow of external objects that lives in a remote service. In other word, this is a kind of cache. Just make sure you clearly separate the caching part with the service part of the external service, because the latter part shouldn't need to be a singleton.
One way you can avoid passing instances of these classes around is by using message passing. Rather than making a direct call to instances of these classes, instead you send a message addressed to the Analytic and SocialConnection service asynchronously, and these services are subscribed to receive these messages and act on the message. Since the event queue is already a singleton, by trampolining the call, you avoid the need to pass an actual instance when communicating with a singleton.