Let start by saying that there is no one size fits all technology
The first two links you share seem to blame a technology for a vulnerability, whereas the exploit was well known and should have been addressed by the app designers.
A relational database makes it very clear whether you have covered it or not, because you do it in the schema (and sometimes settings if there are different isolation or concurrency levels available) and the DB handles the rest. Les development time and fewer bugs. Of course you can still wreck it with bad code, but its a lot less likely to happen.
MongoDB is rolling out new features in v4 to address the above issue
Promised new features may help, but at the cost of performance. I do not know whether what they promise is adequate to fix the issue as your links only states some form of transactions will be available - for this sort of application you need a high isolation level - generally called serializable.
As for the third article, I assume that you must be running multiple instance of mySQL across a distributed cluster.
I am genuinely puzzled by that comment. Why would it imply use of either mySQL or a distributed cluster, let alone both?
Now if you want some specific item, you need to do multiple joins and merges just to get it, whereas in noSQL you access that same data with a simple query on a single document.
At that point you are trading flexibility for performance. It works as long as your document structure (your implicit schema) matches your queries. In an extreme case (e.g. web page maps to data in one document) you may as well store you data in the file system.
IN most cases, given a good schema and using the tools available (indices, well designed queries, materialized views......) you can get good performance. If you still cannot, cache (and you might use a NoSQL database, usually a KV store, for the cache).
So as a result you end up with massive table structures and huge amount of tables all which are mostly sparse
Lots of tables true - but the structure is not so much more complex than that of a document DB as well defined. Lots of sparse tables is either an unusual case of a symptom of badly designed tables. It is also not always that much of a problem - Postgres requires one bit per row extra for nullable columns.