Reasons

Problems of SQL

There is just no real standard. Every product has a little bit different syntax rules, even for quite simple things. This is not obvious for beginners, but leads to vendor lock-in later in the development cycle.
Too many syntax rules. Hard to learn, hard to extend. In 'regular' programming languages, the syntax rules don't change that often when a feature is added (for example, when a method is added).
Data types are not portable amoung database products.
Size restrictions in data types seems to be not modern. There is no maximum size for Java Strings, and most people don't complain about that. Some developers (or is it project leaders?) often set the maximum size of a VARCHAR column too low at the beginning, and changing it later is a waste of time.
No standard for autoincrement columns / sequences.
No Unicode support.
NULL is not equal to NULL. This is a major headache for many queries, for example where two tables have to be compared to find out differerences between the data. Actually, in SQL, NULL=NULL is neighter true nor false . Another example: it is not commonly known, but in a unique index, multiple NULL values are allowed.
Hard to integrate into a programming language like Java.
It is case in-sensitive.
Quoted names that are case sensitive and allow spaces in names. Other programming languages do not allow spaces, there seems to be no good reason to support that.
If there are many columns in a table, 'column counting' is required. Example: INSERT INTO TEST(many columns) VALUES(many values).
No syntax for managing databases as a whole.
No standard UPSERT command (INSERT if the row doesn't exist; UPDATE if it exists).
No standard way to detect if a table (index,...) already exists.
Different products have different namespace mechanisms (schemas, catalogs, databases).
Comparing complete rows is not simple, because the complete column list is required.
Nobody is trying to clean up the SQL grammar.

What did the ANSI commitee (that defines SQL-92 and SQL-99) wrong?

They didn't do anything wrong. In fact, what they made is absolutely correct. This commitee consists of the existing database vendors. The standard reflects as good as possible what these companies have built. The commitee did never change the behaviour or syntax drastically, because this would break existing applications, and would mean the existing database vendors would have to change their existing implementation without a real benefit. Many database vendors are not interested to standardize everything, because they could loose existing customers if they did. Many companies live from vendor lock-in (most applications run only with one, or few, of the existing database products).

What ANSI did was adding new functionality to the standard. This remindes a little bit of C++: it is a good language, but very complex, because people added too much. Java is a new language, and does not have to take all the old things from the past with it. Java has become very successfull, even it is only a subset of C++ (well, almost). What is wrong with C++? It is too complex. What is wrong with SQL? It is too complex, and the products do not follow the standard. What is wrong with the people that define C++ or SQL? Nothing.

Are not Object Databases the future?

Object database do not have a big market share at this time. There are several reasons why:

There is no standard that is convincing enough (when compared to SQL).

The relational databases are more advanced and cheaper when compared to OODBs (Object Oriented DataBases).

Many relational database system do have now some OODB features, but they are not widely used.

What is the future then?

Hard to say, of course. Maybe OR (Object-Relation) mapping products/standards, that simplify development. Are Enterprise Java Beans a Object-Relation mapping? Is JDO (Java Data Objects) the same? But this products are still using an underlying relational database. Additionally, it looks like the Servlet / JSP (Java Server Pages) part of J2EE (Java 2 Enterprise Edition) is actually more successfull than the EJB part. That means developers are using JDBC directly more than the abstraction of it.

Chances are very good that relational databases will play a very important role in the software industry in the next years. And even if they do not, a new data access language will help in any case.

It is time for another data access language.