不是正确的思路，而且逻辑有问题。
你做游戏，用引擎内的工具也好，用自己写的工具也好。终归是要解决实际的业务开发需求。
你看Unity的这不好那不好，可你看出来Unity为什么用这种方案？为解决什么问题了没有？无非就是它解决的问题，你也需要解决，或者它解决的问题你不需要两种结果。
有了这个结论后，再判断是否需要用Unity提供的工具。
也就是说其实你的实际需求是，有一个业务逻辑，有一个待解决的问题。找到一个工具，看它是否解决了你需要的问题。这里工具是否是引擎自身的，还是自己写的没关系。
而你纠结了那么多引擎不好的地方，无非就是引擎本身工具解决的问题，你不需要而已，或者你觉得它没有解决你的问题而已。
认清了问题，就可以优化工作流，进而优化工作效率。
与其纠结是否用引擎本身的东西还是自己弄，无非就是几个问题。能不能写？有没有时间写？有没有时间维护？有没有比写它优先级更高的需求？
最怕什么呢？最怕对引擎内的功能有偏见，一看到是引擎自己出的，看也不去看了解也不去了解。就开始弄一套自己的轮子。弄到最后，尾大不掉了，维护成本也高，学习成本也高。回头发现引擎本身那个东西也能用，效率可能还比自己写的高。
看项目体量和要求吧，通常来说，没特殊要求，就怎么方便怎么来。
现在都是快速开发，有问题，事后迭代再改就好了。
你需要的是源码版引擎，bug靠猜解决确实是个痛苦且搞笑的过程，恰好很多unity开发者都是靠猜来回避引擎的bug。
自己写的东西专用性更强，更好把控。如果是独立开发，你完全可以想怎么来就怎么来。
写图形交互的小项目，要么我就不上引擎。上了引擎，我就选择相信引擎，直接用它提供的东西。但是，我不喜欢用插件（尤其是非官方的）还有引用外部框架，库。
unity的序列化我没遇到什么大坑。为什么你会认为这个东西不安全？
自己写unity的shader也可以。自由度更高，只要你熟悉。物理引擎也有很多选择，不过接入起来更复杂。
如果不是轻量级项目，偏通用性的话。不考虑效率（其实很难不考虑效率）。需要考虑的是
你的开发流程是需要团队匹配的。你的代码架构是不是还可以，统一，通用，复用率高。
你的代码有没有更好的设计上的优势，如某些场景，性能更高。内存占用更少，GC更低。更清晰的逻辑，调用，更好的可读性。
对于项目未来的扩展，你的工具能不能跟上需求。容不容易接入外部东西。
技美来扯两句吧，我是从U3D 3.5版本开始摸的，之后那几年 4.X用的最顺手，由于移植成本高所以5.X只用过一年，之后就直接跳到2017，现在用到18，连19暂时都没怎么碰过。没办法，几百个产品，想要移植非常困难。有的版本之间效果不兼容，一会着色器没了，一会摄像机滤镜脱绑了，各种问题。而且就算你移植到高版本了，性能提高了多少？效果能提升多少？并不高，工作量还贼大。
以前的版本，引擎自带的效果类工具是真心的少，少的揪心，确实完全可以当它是个啥效果都没有的管理器，想要做效果提升：你要么去商店买别人写的插件，要么自己写，而且它自带的那些玩意都特别耗。着色器？就那几种，连最基础的一些需求都做不到，我们当时开发的时候也是大部分东西都是自己写，连GUI都不用它的。美术角度，你用自带工具玩的再溜，吭哧吭哧搞出来的效果也就UE的默认渲染水平。老版本最锻炼人的地方就是找素材找滤镜找着色器，然后自己东拼西凑，慢慢练就了一种上班就先逛蛮牛、某宝、之类各大素材站的习惯。
之后一些版本里面的内容确实有所增加但是依然不够用，好在网络上的插件工具越来越多了，基本可以满足产品的正常需求，但是性能这方面还得自己去想办法优化，但凡有针对性的效果需求，最好还是自己写。就现在18-19版本引擎提供的那点工具实现的效果，在整体效果中可能只能占到15-20%的样子，其他依然全靠外部资源和自己写。
程序方面我不知道，反正美术方面，先不说性能如何，离开了第三方资源几乎活不了，至今依然如此。对美术来说，真不是不愿意使用引擎提供的工具，而是太少太少了。
一般做出这种选择是因为对Unity引擎不熟悉。在不熟悉的情况下这是比较保险的策略，可以避免开发到后期遇到大坑的问题。等你用Unity做过一个项目以后，知道每个功能的优点和缺点之后就可以做更好的取舍。
序列化失败是啥意思？
这不是你自己的游戏么，如果种种原因序列化失败，重新build一下不就行了？
这思路当然是对的，难道……你这么没自信连自己为什么对都要问问嘛？那我来给你分析一下好了。
首先是要用只能用自己理解原理的工具，如果不了解原理请不要轻易使用。比如要做动画spin和dragonbone这种的，如果你像我一样早年就做2d游戏，知道比如snk、gameloft等早就是这样用clip拼frame的做法，并且认同这个做法在这个项目是对的（不同的项目用的这种策略肯定是不同的，因此针对项目这个环境用法是有对错的，比如微信小游戏就不该用这种clip的策略，而应该直接是序列帧为上策），那么你图个方便不用自己写个编辑工具就去用它。大多工具本质上只是解决一些编辑麻烦和帮你写了一些体力劳动的代码。但是为什么你必须了解原理呢？因为很多这种工具并不单纯，作者会一厢情愿的“多管闲事多吃屁”多出很多不必要的内容来满足“通用性”（这也是绝大多工具和框架的问题，总以为可以支持的多就是好，其实恰恰相反）。所以当你了解一个工具他要做的事情的原理的时候，结合你的项目去判断该不该用它，因此至少你得明白原理。这样在功能不完全满足或者出现新的需求可能对功能以及已经完成的工作产生影响的时候才能及时找到策略，而非直接拒绝需求。
其次是绝大多数工具尤其是unity和ue提供的那些，永远只考虑从0到1编写一次，但是绝不考虑编辑完了我要怎么修改，包括unity本身就是如此。这种解决思路通常也很容易出自杠精之口——“只要这样不就行了”。本质上就是他们只解决了“可以用”这个问题，而忽略了游戏开发中0-1只占了10%不到的工作，绝大多时候都是在维护，比如最常见的：难的并不是输入10万条数据，而是当你有10万条数据了，从中筛选出符合规则的来修改，而这些规则往往没有逻辑，比如“带中毒效果的武器”而实际上武器只有命中时给buff，而很多种buff都可以被人视为中毒。unity下很多工具在你开始用的时候，比如做个demo，你从0-1写个demo非常方便，但是一旦需要扩展，麻烦就来了，不是扩展本身难，而是当你扩展以后出现问题，不知上哪儿解决，或者解决起来十分蛋疼，因为很多工具的制作者本身心态就是让你能做出个样子解决0-1的问题就完了，这根本就是不开发游戏的外行思维。
所以当你要用一个工具的时候，首先必须十分了解他的原理，并且十分认可他的做法在项目中的意义；然后去看他做出来的东西调整起来是否方便，可维护性是否足够。最后才去决定用还是不用，而市面上99%的开发工具都是不对的，只能忽悠忽悠怀揣梦想但最后只能做个demo的大学生。
有毒吧，游戏的开发成本也是占一大块的。能用引擎工具高效率完成的事情怎么不考虑？效率是生产环境的非常重要的一点。
别人都是尽量自己写物理，预设材质什么的肯定用unity的。为啥你要反着来