While I completely agree with the point that you are trying to make, which is that the performance is almost certainly due to poorly designed database or at least related to database issues, I disagree with one of the assertions that you made along the way.
Besides, there are very few good real-time systems developers that would choose to work on a database program rather than on something more interesting, like... I don't know... shaving toe nails for old ladies. Really, database programming is what people do when they can't do anything else, it's the data-entry job of programmers.
I would like to point out that some of us database developers take great pride in the fact that while your statement has a tendency to be true in poorly managed environments, a few of us actually get really good at our job. I come from a C++ system-level coding background and can easily deal with issues like memory fragmentation, but I actually like database programming.
The problem isn't that all the good programmers do system-level coding only; there is a completely different skill set required for database programming, especially if application design is involved. The problem is that expectations for database programmers have not been as established as those for system level developers.
It is rare to find an application developer/database developer that is really good at their job. Most of them are actually trained more toward system-level development. Academia done very little to help the advancement of application development.
It's not the cast-offs of system development that write successful database applications; it is rather those of us that continue to polish our skills, educate ourselves to existing standards and get involved in the creation of new ones that actually can develop high-performance, easily maintainable, and highly functional enterprise solutions. And we do it with in .NET technologies, among others.