I'm sure there's still a plethora of crashes/hangs though.
The early 5.x cycle was very poor from the standpoint of stability. While going from 4.x to 5.x was great in terms of performance and stock visual quality with the new PBS Standard Shader there were many faults and regressions causing crashes every 5.x release. I have not had issues since the pre-5.3 era. I'm not sure I've encountered a crash since 5.2.
Unity always becomes a gigantic bottleneck for developers later in their projects.
Without knowing the specifics of what issues you're referring to I cannot say whether we've encountered those same issues or addressed them. I know I've personally addressed 2 of 3 of my major problems that I had with Unity3D. The third being something I tried to solve with
Testity which ended up getting canceled after 3 months even though it was working and showed significant promise.
Without knowing what you're referring to I can't really respond with anything but that no tool or framework is perfect and the cost of recreating a similar engine like Unity3D is far beyond my abilities and the time that I have so Unity3D seemed like a solid choice even with their faults.
It's just not worth it for the ease of access/tutorials.
That's not why I choose nor why we stick with Unity3D. We stick with Unity3D due to access to .NET and C# as a language. Which I personally think is a significant productivity boost over C++. The fact that I'm pretty productive and knowledge in both makes Unity3D a godsend. .NET has continued to show promise with netcore/netstandard and Unity3D is moving to support net46 and netstandard soon, they have an experimental build that supports it, and I think it is a promising future. Plus it's easy to find C#/Java developers and even mediocre ones can't crash the .NET/Mono runtime. Though, in the land of C++ segfaults I can't say the same thing.
and their game is getting far along by the time they hit the veritable wall
It's very possible those projects and teams put short-term progress ahead of long term planning, thinking and preparing. As projects get larger and cover a larger set of features poorly designed or planned projects can slow to a crawl. It's always easier in the beginning when you only have a couple dependencies, a couple thousand lines of code and a few features to maintain. Things get much more difficult to keep together as time goes on.
but those harder programming languages are an investment for their more open endedness
There is a big misconception about those "harder" languages. I can do pretty much anything in C# that someone in C++ can do. Let me know when the standard C++ specification includes reflection and type-introspection. If by open-ended you meant I had to write my own reflection engine and rebuild the wheel that Oracle and Microsoft have slaved over creating then sure, C++ is more open ended. If you consider the few things you can do in C++ like template ducktyping or constraintless templating, template metaprogramming or specific control of allocation/deallocation algorithms and timing to be more open then that's not an open I'm personally interested in and I don't find that openness to be anything but a burden on productivity.
Also, I just compiled 33 csprojs for the PSO project in like 8 seconds. Takes me like 30 minutes to compile something like Trinitycore which is C++.
I don't want my life to be this openended: