How 'bout those royalties? That’s a pretty legitimate thing to consider when starting a new project from a business perspective, and can deter more people than you think. Personally I’m willing to deal with them for a small game I’m working on in my free time, but I’ve worked on projects where the company I worked for had the cash to buy full Unity licenses, and didn’t care if we had to put a bit more development muscle into making the game pretty all to avoid what was perceived as unnecessary long term loss of revenue.
For the sake of having at least a vaguely constructive conversation, if you really want to get into reasons to use the likes of Unity over Unreal, here’s one that I don’t feel I need to go terribly into detail about: give me a comparable alternative to .NET’s BCL that’s as comprehensive as it is, as cross platform as Unity presents it, integrates effortlessly with a UE4 project, and functions with no additional external dependencies that I the programmer have to worry about that “just works” natively with C++. STL doesn’t count here as a lot of things (such as XML parsing) fall outside of the scope of STL (however you could write your own or use someone else’s, but that’s besides the point of this exercise). Boost is also disqualified by default for effectively the same reason. UE4’s runtime offers a lot of things, but also falls short or divides functionality in a way that distinctly cements it as a game engine. Of course, that last bit could change based upon user demand.
My overall point here is that in a practical scenario Unity offers everything you need to make a game, and much more. UE4 feels exactly like what it’s advertised to be: a game engine. With Unity I can make much more than just games without any additional dependencies that I need to care about. This is not always going to be the case for UE4 once you start venturing outside of the category of “games”. I also have a few choices about what lighting pipeline I can use for my game in Unity: per-vertex (handy for older cards that barely support SM2.0), per-pixel, and deferred lighting. It’s highly configurable, and offers a lot of APIs out of the box even if its toolset doesn’t quite compete with UE4 1 to 1. That being said, the choice in many cases is going to come down to a matter of preference, especially with Unity 5 coming out before the end of the year. You’ll be harder pressed to point out discrepancies in functionality between Unity 5 and UE4 purely based upon the features they’re marketing for it, however a valid point here would be that Unity 5 isn’t released yet where UE4 has been released since Epic’s event at GDC.
TL;DR, Unity has more advantages to it then you’re seemingly aware of, and as a result of competition will be comparable with UE4 in its current state by the end of the year. Similarly, Epic will likely find ways to leap frog Unity 5 after it’s been released, again, as a direct result of competition. Really pick which ever one you feel suits your needs more, but don’t blatantly say “X is better than Y” without explaining why X is better and Y is worse.