Abstract ADO.NET is trying to make ADO.NET more JDBC-like. Why? Here's a pretty insightful quote.

The most heinous problem is the exception heirarchy. No matter what goes wrong in JDBC, you will get a SQLException. In ADO.NET, depending on the underlying provider is what type of exception you will get. [sic] Using the SqlClient classes, you will get SqlException. Using the OleDb classes, you will get OleDbException. Using the Oracle classes, you will get OracleException. And so on and so forth.

The ADO.NET architecture really is only half-done. As long as you're only using one type of backend, things are great, but one of the best parts of "classic" ADO is the ability to transfer [again, "classic"] ASP 3.0 code from a, say, SQL 7.0 backend to Access 97 with the change of a connection string (problems with the way Jet handles date strings, etc, ignored for now). JDBC is similar.

It'll be interesting to see how Abstract ADO.NET works out, and how they'll write code so that it doesn't lose some of the advantages gained by having finely tuned object models for many different rdbms systems, not to mention how it'll handle 3rd party ADO.NET connectors written in the future.