Well... that's a large topic.
But, we're very happy with Unity, and I'd definitely recommend it. UDK isn't really something we'd be interested in because it's focused solely on 3D. Also, the price of that is crazy -- the royalty share would have cost us well into the six figures, whereas Unity cost us around $3k. So it's no comparison.
When it comes to Unity, our goal was to be cross-platform, high-performance, still coding in C#, and lacking in prerequisites that have to be installed on the client before running the game. In terms of being cross-platform and prerequisites-free Unity was a pure, unadulterated win. In terms of still coding in C#, that was a huge win as well, although Mono does have some drawbacks: mostly in terms of RAM usage and a crappier GC (at the moment), which led to some pain for us for a while. And an 800mb heap size limit, which was trouble for AI War off and on (fortunately, textures and things don't count as part of the heap).
When it comes to being high-performance, that's been a pretty even swap in the end. For a while performance in Unity suffered some compared to our older solution in SlimDX. But as we got more into the Unity side of things, and started replacing more and more of their engine-specific objects with our own stuff, we got around that. Now performance is actually better in a lot of respects. But it took a solid 3-4 months across Tidalis, then AI War, then even some AVWW to really get all those kinks ironed out.
My general advice, for anyone using Unity to do 2D:
1. Use sprite dictionaries, either through your own library or one of the ones available on the unity asset store. Anything that keeps your number of draw calls down is a must.
2. If you need to draw a lot of lines or similar, use vectrosity. No question about it.
3. If you can, avoid the GUI system of unity like the plague. We use it, and I think Keith and I are both sorry we do. There's a better version upcoming supposedly, and there are third party GUI systems on the unity asset store, though. The reason for this is that it's kludgy and inefficient, and causes a lot of heap allocations it shouldn't. Among other things. Specifically avoid their GUI.window stuff, as it is the most prone to bugs.
4. If you're doing your own custom stuff and have a large number of objects you need to draw onscreen at once (hundreds), then I suggest forgoing GameObjects. They are the cornerstone of normal Unity development, but we don't use them. We have our own custom rendering call stack that uses DrawMesh.
5. If you've got a large 2D game with lots of stuff you need to dynamically load, you also don't want to use Unity's normal asset pipeline. Instead you want a custom solution using their WWW class to read stuff asynchronously off your disk, and then you want to manage all that yourself in terms of what stays in memory and what gets unloaded, etc.
6. If you plan on porting your stuff easily to iPhone or similar, then probably you shouldn't do #5, and maybe not #4. But on the PC and Mac, I couldn't imagine any other way of working with Unity.
In short, I think that it's a great engine, the best one around you can get, and the community support is generally above average for them, too. Support direct from the company... I'd say it's somewhat below average, although they are
reasonably fastidious. Compared to other professional solutions for professional companies, anyway. It's miles better than anything that's not professionally driven, with a few shining exceptions like SlimDX, which has tremendous support.
BUT, as part of that original "in short" comment I strayed from, for our purposes Unity Pro is absolutely needed for its bare-metal access, and we wound up stripping the unity engine down to that bare metal. We don't use their asset pipeline, their game objects, their physics, or their networking. We DO use their bare-metal graphics capabilities (which are awesome), their input capabilities (also great), their camera system (also great), their audio system (really good), their shader system (REALLY good, but I wish documentation was better), and other miscellaneous stuff.
I have no intention of switching engines anytime in the foreseeable future, if that's any answer. There are things I don't like about the engine, but that's going to be true no matter what. And the pros vastly outweigh the cons for Arcen's specific purposes. There's no other engine that comes close and that's cross platform and that's C# that is out there at the moment.