首先，ECS设计的优缺点其他答主已经回答的很多了。那我就说一下自己的判断（纯属猜测）：
限定条件：
<li data-pid="KO-YnbOW">1、大中型游戏开发；小型游戏因为周期短、人员少、题材多变等可以架构设计非常灵活，因而不做讨论。<li data-pid="cUXwPu8E">2、国内手游开发；手机和PC、主机等，国内和国外游戏很多情况下在制作理念、方向等存在不小差异，因而在这里重点讨论国内手游的情况。<li data-pid="f5h1zFWQ">3、短时间（3年内），毕竟时间长了什么事情都可能发生。结论：
<li data-pid="OzvfEwJ0">1、纯的ECS架构短时间内不会成为主流；<li data-pid="GyEOJ_br">2、ECS的设计理念会逐渐渗透到当前游戏架构设计中，会出现大量的混合式设计；分析：
对于很大一部分手游来说，热更新是标配，诚如很多答主所说目前的热更新方案（lua/ILRuntime）都会影响ECS本身的Cache友好和多线程加速功能。因而目前ECS还剩下的比较大的优势就是解耦了。
国内游戏发展到目前，很多开发组都会有一些成熟的架构或者方案，这些即是历史财富又是历史包袱。这使得很多问题在使用传统架构时候可以有很成熟的解决方案，而如果换用纯的ECS式架构，很多问题的实现都需要重新摸索。
ECS在很多地方并不是特别合适，比如很多答主提到的UI模块等。游戏开发过程中各个模块错综复杂的关联关系，及策划设计的频繁改动，都会导致很难抽象出一组既符合Cache友好又相对独立、还正交性良好的Components；
但是ECS在解耦合、灵活性等的优势又是十分巨大的，因而短时间内在存在历史包袱的情况下的一个折中选择就是：
ECS主要处理Map相关，如Actor等。这些在开发中需求相对稳定，并且很多开发组已经做了EC化，可以通过简单修改无缝过渡到ECS；同时，在混合式ECS中Entity可以不必只作为一个ID存在，Entity可以实现继承等。这样可以无缝兼容 继承式--->EC--->ECS，不同的部分可以根据需要写到Component还是System还是干脆写到子类里。虽然没那么纯粹并且牺牲了很多ECS的有点，但是可以实现从目前的架构的无缝升级。
对于像UI等部分依然维持MVC/MVVM等的设计，这在部分中ECS暂时没有什么比较好的方案。
我自己一番尝试后，最后放弃 纯粹的ECS
根据自己需求重新设计自己的框架。
没有什么框架是未来主流的。只有合适与否，没有什么啥都适用且非常强大。比如拿ECS做做界面逻辑，或者拿纯OO去搞那种很需省带宽的底层通迅……都是不怎么理智的行为
肯定不是啊，未来架构是DOTS。
DOTS - Unity’s new multithreaded Data-Oriented Technology Stack
为什么你们都要叫做 ECS 呢？官网明明不这么叫的。
你觉得面向数据编程不舒服，可能是你没有去维护过复杂的大项目，特别是没做过服务器开发。其实游戏的逻辑说白了就是数据，如果给你一个功能，你能快速的总数据结构描述出来，你就很快明白怎么做了。把数据和逻辑拆分开，需求的变更就是改数据结构或者改对数据的处理方式。
没有那种方式是最好的，而是要选择最合适的。不要对某种方式抱有偏见，开发过程中也不是非要用一种方式。
ECS当然值得一用，也值得你花时间去实践它，等你实践之后，你对ECS相对EC的优劣，应该会有更深刻的认知。
而我的观点是，ECS能解决一部分问题，但ECS在解决这些问题的同时，也引入了一些新的问题。
没有银弹。——佛瑞德·布鲁克斯
ECS架构是针对游戏行业专门提出来的一个框架，它是专门为游戏逻辑编写设计的一种架构，你到其它的行业，
这个模式可能不那么使用，可是在游戏里面非常实用。因为游戏世界是大量的游戏物体的运算和迭代。
一个游戏角色：寻路，导航，AI，攻击，被攻击，技能buff等，而游戏世界里面每个角色基本都是由这些功能组合而成。
所以我们可以把一个游戏角色看作是一个Entity, 而每个功能需要的数据，我们可以看作是ComponentData, 而完成这些特定的功能，我们看作是System, System 算法使用ComponentData迭代计算，就不用管到底是来自哪个实体了，哪个实体要哪个功能加一个对应的ComponentData然后再进入System迭代即可。所以将复杂的游戏世界的设计变得非常的扁平化管理。
这个就是大型的游戏公司都采用ECS来做大项目的原因就再这里，相比传统庞大的继承体系，这个会更有优势和更好维护。
ECS 更好追踪性能，每个功能独立迭代，到底游戏世界里面按个功能迭代占用的时间多少我们都能很方便的找到和快速的定位。比如，整个系统AI迭代，用了多少时间，都非常方便的能计算出来。
ECS还有很多其他的优点，这里就不过多的讲解了。具体可以看看下面这个视频教程
两小时搞懂ECS架构
为什么是未来的...
在公司的项目用的unity的entities，截止到今天大概快一年了；自己的独立游戏项目用的是一个轻量的ecs框架LeoEcsLite。当然都是在gameplay部分用ecs，UI和平台业务部分都是采用mvc设计的。
先讲一下好处：
[*]一定程度上做到了有效的解耦
[*]配合job system效率有了显著提升
弊端（或者说目前遇到的问题）
[*]某种程度上来说，不够解耦：新增一个系统时，这个系统的执行顺序该在哪些原有系统之前，哪些原有系统之后，需要根据具体情况分析。
[*]有些情况不适用：例如技能和buff系统的设计，若是根据技能、buff效果划分成若干组件，然后由各自对应的系统去执行，那么系统之间的执行顺序就是一个很大的问题。
举一个例子，一个技能的效果是命中时给目标造成10点伤害、1s的晕眩buff，5s的无敌buff。
[*]在技能命中判定与结算的系统（这里简单的将命中判定和结算放在一个系统里执行）中，检测到两个一模一样的技能命中了角色实体A，根据技能的效果，创建带若干buff创建命令组件的实体
[*]负责处理buff创建命令组件 的系统中，一一创建具体的buff实体，并在buff实体的组件上，建立起和目标角色实体的弱连接。
[*]在伤害buff结算的系统中，进行扣血流程
[*]在晕眩buff结算的系统中，合并计算角色的晕眩状态层数
[*]在无敌buff结算的系统中，合并计算角色的无敌状态层数
那么这边就出现了问题，若按上述的做法，将buff按类型分开结算，若先执行无敌buff的结算，则原本该扣的10点血无法正常扣除；若先扣10点血再执行无敌buff的结算，则同帧命中时，会先扣除20点血后才添加无敌buff，也不符合原始需求。
简而言之，若按buff类型拆分系统，那么技能命中的时触发的若干buff无法按照配置的顺序执行，而是根据系统的顺序执行。
而若是将所有类型buff在一个系统中完成结算，这个系统就会很庞大，所以如果采用这种方法，需要对该系统内的逻辑按照OO的思想进行设计。
当然不能，框架，或者说架构，就是工具，为开发服务的工具，目的可以是提高性能，提高并行开发效率，提高后期维护效率，降低维护成本等等。
就像一个铁匠，一个农民，一个维修工，他们一个擅长锤子，一个擅长锄头铲子，一个擅长扳手螺丝刀。然后这时候有个人突然跳出来，说“恕我直言，在座的各位，都是乐色，未来的主流工具应该是撬棍！”
铁匠：？？？？
农民：？？？？？
维修工：？？？？？？
没错，抛开需求抛开项目谈“未来主流框架”，比纸上谈兵还不靠谱，简直是不能更流氓的耍流氓。
ECS确实用来解决耦合度更高的问题的时候有奇效，不过个人感觉上确实在做UI方面还是MVC或者什么MVVM之类的分块设计更适合，毕竟耦合度复杂度的高低其实更多取决于数据的复杂度和关系紧密程度，这样ECS在解决数据的复杂度上可以更细小的粒度切入，拆分的更加容易组装复用。可是对于UI什么的，其实更多方面的并没有数据而是展示等等，也就没那么贴合ECS的思想了。
个人在写小游戏的时候，本来想采用纯ECS架构实现，可是1.碍于没有可视化编辑器，很多组件的编写其实都是得通过自己代码编写，添加与否同样，很费时间。2. 游戏复杂度比较低，传统的MVC分块后，用简单的EC就可以解决，也就是现在老的Unity版本或者CocosCreator使用的模式，通过E来容纳组件C，而组件C定义了数据之外还包括了system的行为定义，其实也就是抄unity的一些东西。因为游戏较小开发起来也很方便。
个人总结：ECS确实用来解决数据-行为复杂程度高的情况更好，对于UI或者显示方面，因为对于数据的关系不那么高，也就可以使用其他的比如MVVM或者传统的面向对象形式开发更加方便。