Singletons were perhaps the worst possible example of code snobbery: code snobs (real code snobs, as in "no true code snob") typically detest the singleton pattern as less maintainable, less testable, and less flexible than dependency injection.
However sometimes a singleton is in fact more maintainable and improves the code massively. Nor do they have to be less testable when implemented well.
None of which detracts from the article which is about consistency in the code base. A knew jerk reaction to the singleton completely misses the point.
It enabled us to decouple some code deep down in our architecture and enforce some constraints around the use of this particular piece.
When you actually need a singleton it's best to use one and call it out as such so people know what they are dealing with. Dependency injection will often be passing around a singleton everywhere without people being aware that it's a singleton and all that that means.
I suspect dependency injection has the same problem: you could achieve the same results in a non-object-oriented language.
Better a consistent-but-suboptimal architecture than a random grab bag of varying quality.