This is an interesting way of looking at the problem - as a 'TCO' of data stored. It's not one that I generally go to, but perhaps I should more.
I think the argument against it is that developer time and productivity is worth a considerable amount for many companies, and working with tools (DBMSs in this case, but it applies to lots more) that speed up application development is often worth more to the business than the basic cost of storing and serving data.
This isn't always the case, at Facebook scale for example, it might be that the most efficient use of money is to use (speaking entirely hypothetically here) is an Oracle database instead of MySQL, and instead hire twice as many developers because they are half as productive with it. Maybe that would be a good trade-off? However, at many (most?) companies, I suspect that the better trade-off would be to hire fewer developers and use tools that are more expensive to run.
If product X is free, but requires hard to find skilled operators and doesn't have well established operational best practices, paying über dollars for Oracle might be the smart move.
Where I work, location and policies for hiring contract staff make a product like Mongo high risk for data we care about.
I think the argument against it is that developer time and productivity is worth a considerable amount for many companies, and working with tools (DBMSs in this case, but it applies to lots more) that speed up application development is often worth more to the business than the basic cost of storing and serving data.
This isn't always the case, at Facebook scale for example, it might be that the most efficient use of money is to use (speaking entirely hypothetically here) is an Oracle database instead of MySQL, and instead hire twice as many developers because they are half as productive with it. Maybe that would be a good trade-off? However, at many (most?) companies, I suspect that the better trade-off would be to hire fewer developers and use tools that are more expensive to run.