It's one of those ideas that sounds great when you hear about it in college, but doesn't really work when you try it in practice. "Universal" data abstraction layers like ODBC and object-relational mappers like Hibernate, Django, SQLAlchemy, etc. have been around at least since the mid-90s and perhaps before.
The problem is that all those inconsequential differences between data stores are really important. The article explicitly says "Scalability and performance are outside the scope of this", but in real-world software, scalability and performance matter a lot. When we'd tried out Hibernate for a past employer, performance dropped by 80% - data operations were now taking 5x as long to complete. You can recover much of that by tuning your mappings, but by then, you're pretty much writing SQL anyway, and your app wouldn't work with any database other than the one you tuned for.
Also, nearly every app needs its own data abstraction layer, one that works with the particular operations and domain objects of the app rather than tuples and records and tables. At this point, there's little reason to go through another abstraction layer, adding complexity and slowness to your program, when your calls to the data store are already localized to one module.
The Turing Tarpit: Anything language powerful enough to express programs in is in fact a programming language, and the flip side, any problem complicated enough to irreducibly require a programming language to solve is intrinsically complicated. It's all fine and dandy for the first 20%, but then it starts exploding in your face.
It turns out we have general-purpose libraries for dealing with data already. We call them "programming languages". If there is some way to simplify the problem in the general case in such a way that data manipulation no longer requires a full programming language, nobody's really proved it. If your do create an "ORM" or some other mapper that is somehow simpler than using a full conventional language, than ipso facto your mapper or whatever is too simple to handle the full complexity of the problem.
I'm not 100% convinced this nut is completely impossible to crack, but I am sure it would take accommodations on both the data and the programming side (much of the pain of this process is self-inflicted with bad paradigms and bad programming, but probably not 100%), and it sure as heck isn't as easy as it looks when you just look at it. One of the ideas in my head is to take a crack at this problem myself, but I've been telling that one to shut the hell up and go back to hiding in the corner.
It's a bit old, but the Database Template Library is worth checking out. The DTL presents ODBC records as STL objects, enabling the use of all sorts of yummy STL algorithms!
Ruby ORMs like DataMapper and ActiveRecord are datastore-independent and provide similar functionality. I'm sure similar ORMs exist for other languages.
EDIT: It seems like a simple idea, but I'm wondering if the execution has failed or if it was adoption or if this is truly an original idea.