For simplistic systems, with very basic data storage needs, I've often gone with a custom data layer which persisted to XML. However, to answer your question properly, we'll have to look at it from the perspective of most large companies.
Why are we even keeping SQL and a SQL database as the back-end?
One of the best answers that I can give you is that databases tend to outlive the systems that use them by far. Business data has meaning long after the front-end's technology has become obsolete. Refactoring or rewriting code (a task not taken lightly when it comes to large systems) is far easier than refactoring or redesigning a database. It's more than just not having the necessary tools and techniques (TDD / automated refactoring, etc), when you are working with existing data, there are many other factors to consider, such as downtime (changing things around in a 20TB DB takes a while).
Also - SQL, is a very good 4GL for accessing data. It abstracts away a lot of the complexity, and still allows for excellent performance (when things are done correctly).
Why doesn't the ORM just persist objects to XML or a binary file(s)? Why bother with all the overheads and difficulties of administering a database server?
If you think about what you are saying for a minute, you will realise that you are describing a database server all over again. The actual storage mechanism databases use is a highly optimised binary file. If you didn't use a DB server, you'd end up reinventing indexes, and then reinventing atomic transactions. Also, if you think administering a DB is a pain, you probably haven't tried to administrate millions of disparate XML files.
Is this the way of the future?
The DB world is certainly going to change a lot in the next few years, with "NoSQL" showing many benefits. The need for a mature, reliable way to store, retrieve and manipulate data isn't going anywhere though.