可以从MongoDB的几大优势来看为什么使用它：

1. 动态数据模型

2. 水平扩展

3. 高可用

你已经注意到数据模型的问题了，但是还没发现它的强大。可以说MongoDB的用户有很多是冲着这点去的。举个常见的例子，同样是一件产品，你有CPU内存硬盘，我有颜色尺码款式，你试着用关系模型描述看看是什么样子。这只是一个最初级的例子，企业用户会遇到比这复杂百倍的问题。历史数据，从不同公司购买的系统，不同部门收集到的数据……一个大公司中查一个客户的信息登录十几个系统是再平常不过的事情了。MongoDB常常被用于整合这些异构的数据中，这就是动态模型的威力。
水平扩展。这个数据爆炸的年代搞个上千万数据似乎不是什么难事。MySQL支撑千万数据已经开始吃力。如果有上亿怎么办？10亿怎么办？分库分表？程序复杂度要怎么办？异地多读多写的应用又怎么部署？不妨看一下MongoDB的分片原理。
高可用。现在的老板一言不合就要7x24，SLA要4条9，你准备怎么办？请参考MongoDB复制集解决方案。
最重要的，上面这些功能只需要简单的配置就能实现。我不是说里面没有坑，任何一项技术都有坑，这就是为什么我们需要经验。
任何技术都有其适合和不适合的地方，所以看到诸如"Should Never"之类的字眼，或者有哪篇文章胆敢说"Should Always"，我都是“给你个眼神自己体会”的态度。作为技术人员应该更客观一些看待问题。

EDIT

因为下面已经有人@java_c 表达了明确的反对意见，所以在这里再多说两句。我的观点在上面最后一段已经表达得很明确了，再强调一遍：“任何技术都有其适合和不适合的地方，作为技术人员应该更客观一些看待问题。”。如果做不到这点，那我们也没有讨论的基础了。
不懂为什么要扯年不年轻的问题，MongoDB大约有8年历史了，但是跟RDBMS的几十年来比，毫无疑问是一项年轻的技术，所以这个为论据想要说明什么问题呢？年轻的技术就没有存在的必要了？就一无是处了？
为什么用JSON和JS语法做查询语言而不用SQL，你归结为一个“蹩脚的查询语言”，“为了不用SQL”，以下是wikipedia对SQL的解释：

SQL (Listeni/ˈɛs kjuː ˈɛl/,[4] or Listeni/ˈsiːkwəl/;[5] Structured Query Language68) is a special-purpose programming language designed for managing data held in a relational database management system (RDBMS), or for stream processing in a relational data stream management system (RDSMS).

明白了吗？要求一个NoSQL数据库去用SQL做原生查询语言还觉得理所当然？虽然不想做更多的解释，但是我想你接下来又要提Pig Latin了。即便这样，它无非是一个SQL到Map/Reduce的转换器而已。你要类似的东西MongoDB也有，请看BI Connecter的相关资料。请把表面和本质分清楚，不用SQL的深层理由还是在暗示不要用SQL的思路来使用NoSQL。
最后，你所说的“乱七八糟瞎折腾”也正在我想对你现在这个回答的总结。

最后补充一次

Journal是1.8就支持，2.0就默认开启的防异常中断措施。那大概是5、6年前的事了吧，怎么会到现在还在纠结5、6年前就不该纠结的问题……
一直在说客观地看待问题，RDBMS几十年的发展在你眼中就一无是处吗？所以NoSQL支持一些RDBMS的特性有什么问题？要么一棍子打死这个，要么一棍子打死那个，能不能公正客观一点？
拿wikipedia的引用只是在说……再把上面的黑体字读一遍。一会在说NoSQL不应该走RDBMS的老路，一会在说NoSQL应该支持SQL查询，对你这种摇摆不定的观点我也不知道从何说起了。
关于数据结构，怎么会大多数数据都有结构这种看法？我从来都没发现这个世界原来是这么标准化的吗？反正在我个人看来，范式化才是不符合这个世界的本质的，虽然它能工作。牛顿第一定律也能工作，还要搞什么相对论和量子物理。
最后说说这个模式设计的问题，个人从来都不认为把所有东西揉进一个JSON就是MongoDB提倡的模型。为了反范式而反范式这模型设计的大忌（同样用范式化来设计NoSQL模型也是大忌），要知道怎么设计一个数据模型，请移步data schema design或者多参与社区活动和讨论，或者……老板买个全套服务让原厂上门服务讲解一下吧……

目前正在使用mongodb，正如@Mongoing中文社区 所说涉及到了商品的存储，每个商品有很多规格，在查出该商品具体数据的时候，正常的关联模型会出现很多表的关联连接才能收集到完整信息，而mongodb里面我把所有数据都存在同一条里，查询只要经过一次查询，而且mongodb也提供了对多维数组的数据操作

更新

 DB::connection('mongodb')->table('products')->where(['stock.stock_id'=>1])->increment('stock.$.sold_num',1);
 

查询

 $sFlag = DB::connection('products')->table('goods')->where(['stock.stock_id'=>1])->get();
 $sFlag = DB::connection('products')->table('goods')->where('stock.stock_id',1)->get();//单个
 $sFlag = DB::connection('products')->table('goods')->where(['stock.stock_id'=>['$in'=>[21,22]]])->get();//多个in
 $sFlag = DB::connection('products')->table('goods')->where('spec.spec_name', 'like', '%色%')->get();//like
 

刚开始使用感觉挺好用的，这边我还是把关联存到Mysql里面了当作一次备份

@Mongoing中文社区

我并非否定你们对mongodb发展所做的努力，但是不得不说就凭你们现在努力的时间来看，完全比不上具有成熟底层架构的postgres以及其它商业数据库。

刚开始还用mmap来存数据这么低端的做法就能看出，mongodb太年轻了，相对于它所宣扬的好处，它的不足更让明白的人望而却步。

现在你们在做的各种比如分布式锁的粒度细化，不用mmap的新存储引擎，支持事务性（断电保护）的日志等等，完全在重新走RDBMS的老路。

为了不用sql，用json设计了一个蹩脚的查询语言（就是把很底层的抽象语法树暴露出来给人用）。

等等总总东西，让我觉得你们就是在为了方便操作json，为了Nosql这种广告概念，在乱七八糟瞎折腾。

唯一比Postgres优秀的地方，就是操作大json效率好，而这一点使用的场景，只能说太少。

回复 @Mongoing中文社区 的补充

请不要用“不客观”来评价我的回复，我已经说明了Mongo唯一的场景，就是大Json的频繁修改，其它场景统统弱于除Mysql/sqlite以外的RDBMS。

我说他年轻并非说的年龄，而是说的幼稚。直接用mmap来管理数据，一定程度上方便了开发，这是最原始的做法。但是为什么RDBMS不用的原因是，这种方式无法实现断电等异常情况的数据保护。这么低级的做法会用到一个数据库上可想而知思路是多么不成熟。

现在Mongo也在不断优化，不断改进问题，事在人为，我相信只要有足够多的人努力，一定能在各方面超越现在的RDBMS，但是不过就是浪费人力重新走一遍RDBMS的老路而已，走完了再继续前进，才谈得上进步，何必呢？

你拿Wiki上对SQL的定义来抠字眼有何意义，这个定义是在Mongo出现以前就下了的。逻辑上sql完全可以操作json。

我之所以说乱七八糟折腾，除了上面提到的一开始自以为先进，结果不得不在底层数据管理算法上重走RDBMS的老路以外。功能上schema less是不符合大多数场景的，因为大多数有价值的数据，都有结构（schema）的，Mono将来会不断增加schema的功能，最后做成个四不像。

接下来我要说的不是针对你，是针对一些宣扬唯Nosql论的人，他们只看到了RDBMS外键、唯一键、约束等功能的复杂，以为全部揉在一个json里一下子查出来就叫方便。实际数据库的约束本是功能，比如唯一约束，就算转到了json里存，你仍然要实现唯一约束，不然数据库无法帮你拦截错误的数据，其它以此类推。

有人踩这个答案了

希望能有更多理性的交流，如果不服，接受工作量至多为半天的挑战，你拉出你的场景。我们设计好后，比性能，比功能，比实用性方便性都可以。