100 Gallon Can of Worms
First question is "what is a commodity?". A price of zero for some versions is a good hint, but the other requirement is that alternatives can be substituted and provide the same functionality.
Basic SQL compatibility has come a long way, so with care and for simple applications yes, the core rdbms is now a commodity. For power users it's not the case though.
Ideally in tech development, todays value-add is tomorrows commodity. But vendors want to differentiate themselves in the marketplace and to lock lucrative customers into their platform, while power users have demands for performance and complexity, so we get feature sprawl.
Vendors are motivated to innovate, great, but also to differentiate contrary to commoditisation. The market may demand interoperability, but it'll be slow in coming, and with each industry standard adopted expect yet another set of vendor-specific features.
What gets my goat is where the attempt to add value encourages bad practice. Stored procedures with prefab execution plans reduce CO2 emissions, spiffing, let me feel cool bark pressing against my cheek (matron!), but don't overdo application code in the data storage layer.
And xml in clobs? Afraid I'm with dbdebunk on this, the proven relational paradigm should ideally be implemented in documents, or at least have proper translation at the app code layer for transmission and representation, but don't drag the rdbms back to hierarchical just because the W3C have a hierarchical document world view.
At least one good thing will come of the fiasco, xml document standards will eventually yield equivalent relational standards in the rdbms, then the value add will be relational documents avoiding the hierarchical overhead. Maybe after that and with standard SP languages we could expect full commoditisation with services being the value add. Tweak my cluster Larry-'san, here's a kimono for your trouble.