Doing an implementation for a thing that there must be only one of in such a way that the design allows for multiple future extensions takes more effort. Usually you have a limited budget, and the singleton pattern is very quick and easy to implement.
A global is even quicker and easier to implement, and is arguably less objectionable. Passing in a pointer to an instance is barely more complicated.
Testing the general purpose variant of the design may take more effort. (Yes, I know, using global instances of a singleton may also add to the testing effort, but the discussion about singletons is not the misuse of global objects).
Singletons (and globals in general) are the anathema of testing. Anytime a class calls to a global, they escape your test harness., and you are screwed.
A generalized class can cost more CPU time. I am not saying it will, or that it really matters, just that it may be the case.
Artificially restricting the use-cases of a class to a single instance is the path that requires additional effort here. Not enforcing those constraints is free.
No, just, no.
The factory pattern is based on the singleton pattern. That is, it usually uses classes with a private constructor to force clients to use the factory methods.
If your factories are singletons, then you are doing that wrong too.
What happens when you need to dynamically replace a factory at runtime, or any of a dozen more trivial use-cases?
We're not designing and delivering a composite of multiple cars.
And when you need to instantiate multiple cars in your test harness, what then? Try telling an automotive engineer that he is designing a car of which only a single will ever be built, and no prototypes either...