I've worked with both commercially. Shipped an early access prototype with Unity, currently working in Unreal.
The first thing I would say is that I'm amazed that some people would still rather do it all themselves. Of course, you can do everything that these engines do, and in some cases better. But there is just so much work in these engines that to replicate it would take so long. I've worked commerically on in-house "code what we need" engines, and literally once a week a different artist or designer would come and ask, "how do we do <X>, like in UE4 or Unity" and the answer is, "we don't have that yet. It'll take a couple of months to code it", so it never gets done and everyone suffers.
I'm perfectly happy with Unity for the most part. I use it for my personal projects and I recommend it to newbies when all other factors are equal or irrelevant. But I'm concerned that the success of their Asset Store basically discourages them from improving the core product, which we've seen from them ignoring UI for years and then shipping the new UI in a suboptimal state, for example. Some say the same applies to Mechanim, though I've never used it. And I'm also concerned that they want to get in a toe-to-toe fight with Epic over rendering features while leaving everything else sub-standard or broken. But maybe they feel they have the hobbyists and indie market already sewn up, so it's only AAA left to compete for.
Comparing UE4 to Unity is interesting. UE4 is much more fully featured - the animation system, the controllers, Blueprints, data tables, behaviour trees and tasks, integration with source control... and that's before you even consider the higher performance and scope for graphical quality.
But a lot of things in UE4 are underdocumented or simply undocumented, the community is not very helpful, and there are still plenty of bugs. If you're an AAA studio with a support contract, those bugs will (probably) get fixed for you before you ship. If you're anyone else, get set for hours or days of digging through engine code to try and understand it, only to have to fix a bug in Epic's code. And the code is complex. You get all the downsides of a large inheritance hierarchy with all the downsides of a component-based system, with all the fun of sprinkling magic macros and auto-generated code throughout the code base too. You need to be in it for the long haul, and you need experienced C++ coders to do well. With Unity it's more straightforward; generally speaking, if it's implemented, it's documented, and someone will help you out on the forums if you ask. So a large part of the decision is about whether you're happier digging into other people's code or not.