Proprietary formats
Fifteen years ago, when I first started programming, I used this Visual Basic-esque tool called REALbasic, which let you put together programs in an interface builder and code in a not entirely terrible language. I did some interesting projects back then. They are all lost to me now, because RB saved its projects in a proprietary format.
Unity has the same problem: a huge part of any Unity game is in scene files and prefabs. You can only edit these opaque files via the Unity editor, so if something goes wrong with that, you're doomed. In the case of last week's game jam, a bad interaction caused Unity to silently fail to save scene files. We'd hit save, and nothing would get saved, no error dialog would pop up, nothing. We'd go back to a scene later and find an hour's work missing.
Collaboration is hard
On the one hand, Unity uses a nice entity-component system to let you create behaviours independently and combine them. On the other hand, you need to put together your actual game in monolithic scene files. You can only have one of those open at the time, and only one person can safely work on a scene at a time. Even with a small team of six people this was a pain - how can this possibly work if you have a bigger team?
Model and view are inseparable
Unity's entity-component system is mandatory: Gameplay occurs by the interaction of entities, and these entities mix up the semantics of the game with its presentation. This works OK for certain kinds of games, which are about entities that have a position in space interacting with other entities.
But there's other kinds of game semantics that really conflict with this. If you want to be able to work on game mechanics independently from presentation, you're out of luck. Can you imagine writing Dwarf Fortress or Minecraft in Unity?
I can't imagine writing Airships - hundreds of crew members and modules with complex behaviours that have to be coordinated at high speed. In fact, the UniScreen system in Airships is exactly the reverse of how Unity works: an entity-component approach to views with a monolithic approach to models.
A stifling monoculture?
That being said, Unity is clearly a very good tool. But I do worry about a rising Unity monoculture - most people at Global Game Jam were using it, and when we have game developer meetups, people get quite confused when I tell them I'm not. As I wrote above, it's suitable for a particular kind of game, and so a monoculture means a narrowing of what kinds of game get made. This is the opposite of what I want - I want an explosion of games by different people about different things, games that play and feel differently, and explore that barely-touched huge space of what games can be!