Why?

Indeed, it isn't obvious to me that shims are a better solution as there are some serious downsides. A shim is much less flexible and may need to be changed (and have its security audited) every time the application needs to change how it accesses the database. It also becomes an attack vector. If an application can coopt the shim, then it has full access to the database.

I can see where there could be some interesting usage for the integration of databases and SELinux. Many organizations have a centralized database storing everything, yet few departments actually should be able to see the whole thing. I am thinking of something like a medical institution where the people doing the billing need to know what I owe, but don't need my medical history. Of course, databases already offer ways to limit what certain users see, but security people don't have a centralized way to set these policies.

This kind of integration is one step towards giving administrators one centralized place to set the security policy and I think that offers a lot of benefits. The difficulty of writing these policies in SELinux is an issue, but I can see where companies like IBM would be happy to offer this as a consulting service.