Is Concurrent Mode over-engineering?
如果按照题主对于 过度设计 的定义，我觉得 Concurrent Mode 是没错，毕竟相应 FB 的需求是 React 团队要考虑的，另外基于 React 近年的发力趋向，他们对于 UX 方面的考量显然变得更为重要。
体验一下 新版 Facebook
我谈谈个人的理解。
其实 Concurrent Mode 带来的是两个维度的改变，第一是 CPU bound，第二个是 I/O bound。
第一点：CPU bound
各家的实现差异对应都有不同的优化措施，而对于 React 这种本就在编译期做不了什么优化的，能做的选项就更少了，那么在 runtime 去协调不同优先级任务的执行就显得格外重要。
第二点： I/O bound
这是目前 UI lib 在提供选项所缺失的，那么缺失就需要业务开发者去实现，React 开发者想必并不陌生各种各样的 conditional statements，无论是在 JSX 还是封装藏在各种地方。
其实这样也还好，问题是并不能做到极致，业务开发者是很难处理组件层级优先级和优先渲染必要组件，更别说前置处理未来将会用到的组件。往往结果就是懒得做了，if-else 下班打卡，用户这边也就多被恶心了几秒。
React 的 Intentional Loading Sequences 是根据 最小可觉差 理论带来的进一步实现，在框架层面去处理上述提到的问题（也需要业务开发者在实现上去配合）。
不过框架来做这些事，是真的难，调和适应大部分应用场景这一点就很难，还有很多边界情况的取舍。光是看到关于一个 JND 的时间描述，就改动了好几版，更别说 Fiber 优先级的改动 。
其实我很好奇 Vue 的 Suspense 可以达到的效果
最后说说 DX 方面吧
React 毫无疑问将很多事留给开发者，数数 Hooks 的 api 中关于 memoization 的有多少个；写对 deps Array 你需要了解 Fiber 的基本运作，SO 上有多少关于 Hooks 的提问。讲真，对于一般开发者，心智负担不是一般的重。
当初 Vue 在提出 Function-based Component API（也就是现在的 Composition API）时，我就立刻（其实换个说法是后知后觉）觉得 类 React Hooks 这套 interface 太适合 Vue 这种 reactivity tracking 的思维模式了
但话又说回来，用户群体也是 React 能决定走向实现 Concurrent Mode 这条路的底气之一吧。