Not that any engineer worth a damn would use a database that loses data in the first place.
Configuration data and multiple nodes would be nice.
Regarding NoSQL and "single node" vs. "multi node" -- NoSQL isn't just about scale out systems, it is about mapping the proper type of data store to the data model. If you have a complex relational schema you should use a SQL database. If you need a simple to use document or object store the NoSQL solutions are often easier to code against.
Ironic and invalid generalization. When the tradeoffs are acceptable or preferable (e.g. data persistence is not vital and your application can get better performance out of a database that can "lose data") it makes sense.
Whether it's relevant to the article or not, this is simply false and not constructive at all.