Before we try to argue between UE5 and some future version of Unity with all of the DOTS fully implemented, let’s talk about real blocking issues that real people face today. For example, let’s talk about the 4GB (32bit) file size limit that has interfered with our ability to build large scenes in Unity.
Here are threads about the 4GB scene resources limit in Unity.
I originally posted about this bug in November 2016 when I ran into this problem using Unity 5.5. That bug remained in Unity until December 2019 when it was finally fixed in Unity 2020.1.0a19. The fix was never back ported into Unity 5.x, 2017.x, 2018.x, or 2019.x. The only way to get the fix is through the 2020.1 branch, which is still in beta. To this day, none of the production ready versions of Unity include the fix, so none of the production ready versions of Unity support scenes with more than 4GB worth of assets. Let that sink in for a minute.
In my case, I worked around the problem by splitting my scene into multiple scenes and then using the additive loading option to load all of the assets at runtime. That solution won’t work for every project, though. Some people used asset bundles to work around the problem. Either way, the bug causes a lot of game developers to waste days or weeks refactoring their projects late in the development cycle to work around a major blocking issue. This is literally a 32bit file size limit in the builds, including 64bit Windows builds. The limit was not well documented, and it did not show up in the editor. It was simply a left over 32bit limit that developers would run into in builds when they were testing and releasing their games.
Major blocking issues like this prevent Unity from really going after the 3D photorealistic gaming market. After all, a 4GB limit is pretty tiny when developers are pushing for photorealism. And as I mentioned above, none of the production ready versions of Unity include the fix for this blocking issue. The fix is currently only available through a beta version of Unity 2020.