It's because the wallet is sensitive stuff, and one of the benefits of a database engine is the ACID/atomic operations: it guarantees that data is written as intended or not written at all to the database. No matter what nanosecond the power goes out, it's supposed to be impervious to corruption. When you're talking about private keys protecting millions of dollars, it's a very good idea to have atomic operations... but it comes with the downside that the database is a kind of blackbox and you don't always know what it's doing (hence the 0.4.0 wallet-not-actually-encrypted bug).
The ability of a database engine to provide atomic operations is no stronger than the underlying OS's ability to reliably report that all writes to a certain point have been flushed to disk when asked - using operations that anybody can call from any application, not just a database engine.
The magic that brings an atomic operation to a database is nothing more complicated than replacing "write a record" with the following flowchart:
1. Write a record somewhere that says you intend to make a particular write, including details of the substance of the write, so the write can be repeated if this is the only record of it.
2. Ensure that that record is committed to disk before continuing.
3. Make the write as intended.
4. Make sure the write done in step 3 is committed to disk before continuing.
5. Eliminate the record you created in step 1.
6. Ensure that the elimination done in step 5 has completed before allowing step 1 to occur on a future write.
7. When your program starts up, have it so that it looks for any unremoved records similar to the one created in step 1. Confirm that they were written completely. If so, simply perform the write operation that the record says you planned to make (which will have no effect if the prior write was successful). If such records were not written completely, discard them.
This is simple enough for computer science students to implement in their homework.
The only magic that a database engine brings to the table is the ability for these seven steps to run at a high level of performance with lots of concurrent operations, in an effort to mitigate the performance penalty of tripling the burden of doing writes.
Since a Bitcoin wallet is only updated eternities apart (in terms of compute time, especially when it is limited only to data created or changed by the user), the perceived performance penalty of doing 3 writes instead of 1 ought to be so negligible as to make a full blown database engine completely unnecessary even when ACID properties are desirable.