What's wrong with singletons in general and why would an object could not assume single responsibility (consider an UIApplication singleton on iOS)? I thought, contrary to what you stated, they solve the issue of global variables rather than introducing new ones.
That class extends SPL ArrayObject class which provides array-like access syntax (operators). It does not mean it has to act like an in-memory array, it could read data from disk, session, database or whatever. Delegating this kind of functionality to a single array would simply not work without further abstraction.
Singletons don't solve problem of global variables, they are global themselves.
They are global shared state than can be unexpectedly accessed from any place in the program.
Encapsulation provided by singletons makes them even more problematic than global variables. You can temporarily overwrite global variable, run function that uses it, and restore global value. Singletons can be designed to prevent that, which kills testability of code that uses singletons (e.g. when you need to replace global DB connection with mock object).
Singletons are global variables++. Read up on the capability security model and ambient authority (Mark Miller's erights.org, Gilad Bracha's Newspeak, Mark Miller's JS work eliminating accessibility of document etc. singletons for safely eval'ing JSON etc.) to understand the security, composability, testability and modularity issues with these idioms.
I don't know the particulars of how PHP's ArrayObject works, but take Ruby for example: instead of inheriting from Array, to make a class that operates like an array, one mixes in the Enumerable module (similar to a trait) and implements an "each" method to handle the low level access. All of the other methods come along with the module. In this way, the lineage of a class isn't important; rather, it's what it actually does that matters. (How meritocratic! :-)
But particulars of any language aside, I think this is an important step for PHP. Once a language gives the ability to compose the behavior of a class through traits, modules, mixins, etc rather than standard inheritance, it becomes easier to separate the data that a class encapsulates from the behaviors that it provides—and that, I believe, leads to more modular code.
That class extends SPL ArrayObject class which provides array-like access syntax (operators). It does not mean it has to act like an in-memory array, it could read data from disk, session, database or whatever. Delegating this kind of functionality to a single array would simply not work without further abstraction.