And I don't trust Unity not to close up shop one day and leave me high and dry with closed-source, bit-rotting libraries. Or to not target a platform I care about in the future, again leaving me screwed. I need to control the stack, and Unity is antithetical to this. (This is also why I have moved away from Xamarin's stuff--while enough of their stuff is open that I could spend multiple man-years re-implementing it if it went away tomorrow, it's a much better investment of my time to use the platform APIs directly.)
That being said, I share many of your frustrations, but I think the root cause is that its closed source and not any particular design decision they made. At the end of the day the design is straight forward, but its hard to wrap your head around since you can't easily just look at the code and go "ah ok FixedUpdate gets called right after WhateverFunction, now this makes sense". This is severely exacerbated by bad documentation. Here is one of my favorite examples: http://docs.unity3d.com/Documentation/ScriptReference/Time-s... "Time.smoothedTime - A smoothed out Time.deltaTime (Read Only)." Great, no idea why I'd ever want this or what it actually does. In OS land I'd just go to the function, but not such option here.
On the other hand, I have considerable more faith in Unity than some OS tool to be around in the future and to support new platforms. They have a really great track record of this (they've been around forever), and the fact that they make money is more comforting to me than some random group of developers doing it for the love of programming. However, more tools is better, I'm in no way suggesting Polycode isn't cool or shouldn't exist or anything.
For me, that tool based approach was a deal breaker, didn't care about it's closed source...
Either way, doesnt hurt to have competition :)