I should probably have thought about the third issue more. The Switch to C# over C++ is less about the developers expereince and skill and more to do with third party middleware being compatible with Unity as so many large studios use a variety of tools to make their games.
Although Unity could just make better deals with large publishers like Activision Blizzard or EA to entice them but now that Epic is massive there is no way that Unity can ever compete with them again unless a corporation like Microsoft invest in them just like Tencent did with Epic games. They don't have the resources for it but they are still top of the VR/AR and mobile market so who knows what will happen going forward.

Just to showcase what games are possible with Unity, Wikipedia has a nice little list of games made with the engine:

https://en.wikipedia.org/wiki/List_of_Unity_games

This also includes some AA/AAA games, like ARMA, Homeworld or official NASCAR games.

the issue with number 1 seems to be resolve now with more stable update cycle. But I remember once that I updated it for much needed improvements only to find out that hitbox collision with concave object was now broke and I used it extensively (it was about 5 year ago). So I guess you could choose not to update but you may be loosing on improvements for stability concern. In the end you'd probably branch the project, update Unity, test extensively, decide if you keep the update or not, and workaround issue if you choose to update. All this process is time consuming and more difficult with larger teams. It certainly had an impact on decision to switch to unity back then.

For number 3, you'r right, it's way easier to switch from C++ to C# than the other way. I used to work for a company that made video games for casino machine in C and C++ 10 years ago and switched to work as a software engineers when the company had difficulties and had to let go 1/3 of its staff. Now I work mainly in C#/javascript. The switch was fairly easy for me to do, but it was not the case for many others (mind you some were working purely in C which is not even object oriented). 

Funnily enough this company have now got back on it's feet and started using Unity with a specific Dev team. I know that many, mainly older senior employee, are much stubborn and reluctant to the change thought.

But even without the employee/skills factor. this company had to be ready to let go what was probably $millions in investment over many years in tooling/code base shared with many project to start anew.   

I get that ease of access means a lot of indies and lower budget projects use it, but with UE4 for example I can point to Hellblade or Gears 5 as examples of great graphics using the engine, but even the most impressive Unity games like Recore aren't even close to the same league.

Of course not. Unity is a middleware engine. However Unreal can have some ugly games like Caligula Effect Overdose. Nice art design but man that game is ugly on a technical level when you play it.

You cna make ugly graphics on any engine if you're bad enough at art/tech. The difference is that aside from offline renders, it almost seems like great graphics in-game can't be achieved on Unity.

Unity games can look good but not AAA level no as again it's middleware. It was never meant to be on UE's level. Otherwise it would defeat it's purpose.

I hadn't seen these ones yet, thanks.

I'm pretty sure ARMA Tactics isn't significant in any way... But yeah, there definitely are some nice games there.

For everyone that is saying the tool isn't that much relevance to the quality of the graphics, if that was the case studios wouldn't develop their own engines, unreal wouldn't be updated all the time with some stuff that wasn't possible before being added.
Also if mostly Indies choose Unity but when a studio want to make a good looking AAA game they go unreal or others that should be enough evidence that there is limitations on what is really possible on photorealism on unity.