尽量不使用游戏引擎提供的工具来制作是正确的思路吗？
前提：目前正在使用unity开发一款项目。 也不是说都不要用，只是说要明确判断什么敢用什么不敢用。但是取舍这些是一个很困难的事，要求你至少会用引擎，甚至自己会写引擎。比如弃用引擎自己的资产系统就不太明智，资产管线远远不止序列化，还包含各种热更，版本控制，引用追踪，packaging管理，是要花大精力维护的。
类似的还有level，抛弃prefab相当于抛弃ent/comp的组装和变体红利。并且level设计是引擎Gameplay架构的核心，和资产系统之间也有功能引用甚至耦合，不用这个还用什么unity？如果你坚持不用，层级都要自己组织，后续包个插件一定会产生各种冲突的。
地形或者动画这些大可以找插件，因为unity第一方的实在太弱了。。。。 从整体来看，自己写模块也可以，用Unity提供的模块也可以，用哪个都不为过。
但仔细看描述，题主的想法可能有问题，问题在于题主说：
一直贯彻一个概念就是尽量少用unity提供的东西……总感觉用这些东西做存储有种不安全感。这种想法用一个词概括就是“先入为主”，先假定Unity提供的功能不是很好用、有很多坑，然后在此基础上考虑技术方案。
这种想法很可能偏离了事实。实际开发中最应该避免的思维方式就是先入为主，比如说：
我们这个游戏创建物体太多了，好几百个，一定要用对象池优化一下。Unity的资源管理不好用，一定要自己写一个。monobehaviour不好用，不如自己写个面向对象的框架。
以上三种想法在很多技术团队中都能看到，这些想法很有道理，但在实践中有时是对的，有时是错的。
回到题主的问题描述，内容很详细，针对性谈一下自己的经验。
1、序列化反序列化，ScriptableObject
Unity的序列化工具确实不完善，特别像ScriptableObject这种东西，很适合用在小项目里，但不太适合用在大型项目里。
特别是那种大型网游，动不动几千上万种道具、任务、资源，用ScriptableObject来做基本无法维护。还是得回到传统的“Excel表格”解决方案。用二维表填写大量数据，效果比一个配置对应一个文件容易维护得多。
2、Scene和Prefab存储
Scene、Prefab的问题在于它们的内容比较复杂，不好merge、空间浪费也比较大，不好优化。
但它们也有很多很多优点，最大的优点在于它们是Unity原生的一种存储结构，与Unity的其它功能完美契合，而且能做到所见即所得，查看、修改十分方便。
要知道，一个项目中需要查看修改scene、prefab最多的肯定不是程序员，而是美术和设计师。如果非要自己写一套Scene和Prefab的序列化，那么能否保证美术和设计师查看、修改方便呢？恐怕写一套相关的编辑器更复杂吧？
所以，这些基本功能要不要自己造轮子，必须站在整个团队（不光是技术团队）的角度上，三思而后行。
3、ShaderGraph
ShaderGraph的问题主要在于稳定性、各种手机设备兼容性、以及性能优化方面。
ShaderGraph刚出来时不太成熟，现在肯定是越做越好，小项目完全可以尝试一下。总之用测试结果说话比较好，如果我们做的Shader能运行、性能OK，就可以用。
大项目可能会因为风险和shader管理、优化的问题，采用传统方案。
4、MonoBehaviour脚本组件
其实，Unity的“游戏物体+组件”的框架非常值得推崇。就游戏开发来说，我认为比常见的面向对象的思路好得多。
不敢用MonoBehaviour，只能算是团队偏好，并不能说明它好或者不好。毕竟我也见过大型音游/动作游戏项目全都用MonoBehaviour做的情况。
建议在使用Unity组件之前，先学习研究、再测试，最终再根据测试结果确定是否应该重新造组件。
就算自己造组件，也应该先了解原生组件的优缺点，进行针对性的改进。
否则就容易出现“造了个轮子，结果还不如Unity自带的轮子”这种迷之操作：） 我们从unity4.0开始用，一个30人左右的团队做关卡式MMOARPG，做第一个项目的时候就遇到无比多坑，资源管理、寻路、动画都很不好用，所以当我们有机会推倒重来做个新项目的时候就选择尽量少用unity功能的思路来走，当时还是4.x，所以刚才说的系统还是不好用，所以我们抛弃引擎自带的资源依赖，自己管理依赖（将资源引用拆了自己记录和加载卸载），不用NavMesh，自己写寻路生成、加载和逻辑，动画系统基本抛弃状态机设定，自主控制动作逻辑（仅保留动作融合功能），每一个抛弃都意味着1个高级程序或者主程级别程序一个月以上的开发周期，投入是挺大，但回报也很好，整体基本做到业内比较先进的运行性能与表现性。
但这套东西迭代到5.x的时候就遇到障碍，主要是资源管理系统，5.x开始的资源打包得到了改进，依赖没那么恶心（虽然还不是很好），但因为引入了pbr，光照烘焙加了高光烘焙机制，这套机制会产生一些与场景深度依赖的光照数据，不能动态加载，使得之前的剥离机制在某些地方不能工作，其他还有诸如网格打包时会根据依赖情况来做剔除，也不能纯粹地只打网格等等。
再往后到现在，Addressables出来了，资源管理部分已经比较完善，AnimationClipPlayable也解决了Animator各项短板，引擎都在不断完善，自己写的方案有些还能使用，有些会显得鸡肋。
铺垫完我的经历，总结一下我的经验和建议，自己做的东西容易存在时代局限性，过个三五年后，可能自己的东西会改不动（这几年来我们的框架重构了3次，有些模块已经改不动了，但依然有局部先进性），适应不了时代的变化，当然一般来说也不用考虑这么长远。而用不用unity提供的东西取决于你是否了解它，并自己能否有能力（时间、开发水平和人力）来替代它，想知道未来unity会不会做出你想要的效果，就关注他们的roadmap，或者在Forum问一下他们的技术人员，了解他们的开发计划，如果未来他们会做，你就考虑要不要等他们。
以上建议基于我一开始讲到的人员和游戏类型背景（中小型团队做MMO类型游戏），更大型的团队或者更复杂的游戏类型一般更倾向自己做，反之就倾向依赖引擎功能或者第三方插件等。 其实还好，你说的这两种模式基本都经历过，现在回头看来，其实都做出来了。
第一种 我们把游戏逻辑全用C++写了，包括数学库碰撞物理动画都没用Unity的，导出给Unity用，表现用Unity，好处有没有，是有的，代码可以脱离unity裸跑，可控性强，优化起来也方便，代码一下子见底了，表现层我们倒不太排斥用unity的东西Timeline之类的，主要是那个东西开发成本有一些。而且也不属于核心的东西。
第二种全用Unity的东西，还是大型MMO，我说的是产品级别的成功项目，这个也做出来了，我加入比较晚，也赚的盆满钵满，有解决不了的问题吗？ 其实没有。虽然有Unity源码，但是确实所有的问题没有要用到改源码的层次，都可以查到已有手段解决。唯一让我感觉不可控的地方应该就是优化在不动引擎源码的情况下有上限。解决某些问题需要猜测引擎内部实现，但其实没有那么多。
现在看来成功的产品更重要，如果说代码角度，一味的排斥Unity没有必要。说白了都是代码，要各取所长，做他擅长做的事，为了项目的可控，可以把核心GamePlay抽出去做，方便多项目复用一些底层逻辑和可控性，至于表现层，这种东西出不了什么超级重大的问题，跨平台的渲染Unity肯定比你自己写一个月写的好多了毕竟这么多年的积累，而且这么多项目多过来了。 不正确，有些情况下发现引擘自带工具不完善，你以为是官方技术拉垮，而实际上可能是精心设计和取舍的结果。面对这种情况，如果你是引擎设计者，不如尝试思考：为什么官方不加这个功能，为什么把功能做到这个程度就为止了？说不定能学到点设计哲学。如果你是引擎使用者则应该思考：我目前的需求直接用引擘自带工具是否可以满足，如果不能，如何自己定制、扩展。
引擎就是实现那些最通用、最难、最脏的标配技术，应用层的东西千变万化本来就不可能完全覆盖，需要自己定制很正常，不能偏激地认为引擎垃圾。
当然，目前确实有一些其它引擎早已实现的标配技术unity竟然迟迟没有，这个确实垃圾。 吐槽一句，不考虑效率那完全可以从引擎第一行代码写起了，可是开发产品毕竟与学习研究不同啊。
你的问题描述里，出现了多次“不敢用”，我觉得这才是题主所问的问题关键所在。
即使不考虑效率，你也是需要权衡自己造出的轮子在易用性、BUG出现机率等方面和已经接受过超多用户使用的工具、组件之间的利弊。(其实这个问题通常都没有第二个答案，后者往往比前者强，如果再考虑开发效率，几乎是压倒性的优势，这也在另一个角度符合常说的“不要重复造轮子”。如果非要改，那不如在开源代码的基础上来调整，或许也能获得更好的结果。)
我最近在看《代码大全》第二版，里面也提到了一个关于“造”和“买”的问题的建议，这里也分享一下吧：
如果架构不采用现货供应的组件，那么就应该说明“自己定制的组件应该在哪些方面超过现成的程序库和组件。” 一方面呢，Unity它是真的拉胯，这一点也不用再反复说明了，相当一部分朋友可以写出代替Unity的更好的方案，难道说明人人都是大神吗？不是，仅仅是参照物表现的而已，许多人会说“它这么成功必然有它的道理”，撇开一部分屁股原因，混淆商业成功与技术水平本来就是很愚蠢的，按照这个理解Unity Lab在学术界有很多贡献难道说明Unity是渲染水平最高的商业引擎？这不离谱？
另一方面，尝试造轮子要保证这个轮子的风险和成本低于带来的收益。成本和风险上，项目的快速验证期可以用自带的，再搭建转换方法，在流程不会大变的基础上尽可能快速的转换到自己的轮子。承接上段，商业成功的一个好处就是它的技术再拉胯，工作流程往往是可靠方便的。我先前也写过将Unity流程接到自己的轮子的实践，目的就是让只会Unity的开发者也可以迅速开发不受影响，说句俗的，作为同事，你谁啊你，凭啥我得为了用你的轮子学老半天新API？管你本事滔天，天王老子来了说不学那就不学。人都有惰性嘛，要互相理解而不是对抗。
至于收益这个，就不是工程问题而是纯技术问题了，Rat tail juice即可。 你这套打法是可以有效规避频繁升级导致的各种奇葩状况，是好是坏还是要看你项目的具体情况
我们最开始也是能用现成的工具套件就买来用，等到1年后就出现了以下状况：
1、内置套件被官方弃用，大概有半年多的空窗期
2、第三方作者受不了频繁的兼容性问题，从更新缓慢到弃更，看看已购买清单里黑掉的那两页超级心痛
3、Shader节点在不同平台的一致性有差，想要解决还是得往底层修改，最后还是自己写
4、序列化是个坑
5、体量变大之后想要优化变得越来越困难
……
所以现在已经回归到“画面+物理引擎”的用法了，另外也找了一套同样思路的轻量级环境，双线并行
稳定是稳定，但想要达到原本的开发速度，同事人数已经翻了3倍了 看游戏体量了，类似MMORPG这种体量的肯定能自己造尽量自己造，unity的东西挺多不适应大型项目的，不从底层修改后期优化成问题。
如果小体量的尽量用现成的，后期可以选择不更新，反正差也不会差到不能容忍