The insecure defaults were an issue sure, but anyone installing a piece of software in production without at least reading up on config options needs to find another job.
We need good and consistent rules about this, and "well I was giving it away for free" isn't as clear a boundary as people will think it is.
I would imagine that if someone were to sue MongoDB Inc. today about the issue in the article, their first defence would be clear documentation that explained/recommended production guidelines.
I don't know if D-Link had similar, but then again legal systems sometimes produce weird results that don't seem rational.
I agree that we need good and consistent rules, in addition to that, we need DevOps/SysAdmins/SRE's that are responsible enough to know what they are doing.
Carefully read documentation instead of "quickly deploy" only to come back a year later writing soppy "don't use MongoDB or XYZ because we didn't read the manual". :)
MongoDB is on 3.4 now, so I would rhetorically wonder why some people/companies are still on <=2.6.
If the data that is being ransomed is that important, it'll be a good lesson to those DB maintainers to upgrade and secure their stack.