First off you wouldn't want to use a SQL database for any bitcoin data because you'd have to shoehorn the key/value data into relational format with tables, primary keys and all that special stuff. This leaves only NoSQL databases as a viable option, and wouldn't be end-user disruptive because nobody moves around the chainstate database.
Why don't you like using relational tables and pkeys? Storing your data this way ensures that you are only accessing the exact data you need when making a query.
The schema of a database storing the blockchain, and data required to use a wallet are not going to change. IMO the biggest advantage of NoSQL databases over SQL databases is the flexibility in storing documents/records, but I really don't think that is necessary for any bitcoin-related use case.
Here's the thing though. The current implementation of CDBBatch and CDBWrapper (which you have to adapt after you replace the database) only understand
key and value data, there is no concept of primary keys or tables or any other SQL-specific stuff in it. And since Key and Value types are exposed in an API, it is impossible to drop-in an SQL database in it without changing the rest of the codebase that uses the database wrapper.