The whole point of wrapping a third-party implementation IS to HIDE it. The project using it shouldn't need to know what is under the hood, they just need to know here is the wrapper/API for you to use, if we need to switch drivers, implementations, use a different third-party, you don't have to do a single thing! I just update the wrapper/API (leaving the methods and arguments in tact) and you are none the wiser that we moved from a Content Manager from IBM to one from Oracle or to a internally built system.
In these situations, if my underlying code would need to reflect a singleton, I usually make that (the singleton) a smaller class, and the wrapper/API would then hide that class. This hides the singleton pattern, so all other code would never know the difference but the limitation is maintained to only permit a single thread/instance.
The sole benefit of enforcing a single instance is heavily outweighed by the drawbacks of using static methods and violating the single responsibility principle. When you consider that the same benefit can be achieved in a couple of lines of code (probably fewer than the singleton!) in several different ways, there's no argument for using it. Yes it works, but so would a global variable. It doesn't mean it's a good solution.
I could never agree to that, it is my firm belief that there are situations where these patterns are absolutely a necessity, otherwise their existence wouldn't be needed. Static methods exist to serve a purpose, it is up to the developer to ensure the purpose is met when using it and understanding what the intent is of that ability. I'll never be a person to say "there's no argument for using it". I guarantee there is, the question is, does your situation merit the use of it.
I've seen plenty of times where someone is building a utility class and are not making their methods static even though it serves no purpose as an instantiated class. It doesn't have internal properties, it doesn't need to track any information, each method is self contained and not reliant on other properties. They do it because some one told them static is bad. So you see $utility = new Utility(); $utility->GetRootFolder();, instead of Utility::GetRootFolder(); (the latter being faster and consuming less resources).
I believe there are scenarios that make using a singleton pattern as the best option over an instantiated object (especially in other languages where your assembly may be cached in memory to be used by multiple applications/threads in a service type setup -- getting multiple requests simultaneously).