We're currently developing such a game and Unity 3d could equivalent be named Unity 2.5D.
To give you a good answer a little insight in the development process might be handy:
We've created a tile editor which handles level building using editor scripts. The actual tiles are made out of polygon planes with different collider meshes depending on their texture made into prefabs. They are put into a resources-folder. We can then paint using raycasting directly into the scene. In the tile editor we also have game mechanics so that a level designer never have to touch scripting or an inspector over the whole process. Certain game mechanics can be attached to an existing tile in the scene or stand alone as trigger areas.
We make use of Unity's own level system, this way we can save time and don't have to serialize things. A scene in Unity doesn't weigh much at all looking at file size. Loading and listing levels is all Unity's system where we've listed information in an array-class. This remains quick both in development and in-game.
The scene is separated into different layers, we have a foreground-, background-, decor-, prop-, ai- and walls-layer. For all the layers we've written special shaders that uses only what the layer needs, to keep them at a low cost. Each layer is separated to different z-depths. The camera still uses a perspective view to get that beautiful depth feeling of background moving slower than the foreground while moving. We then lerp the camera to the player position on the XY-axes and use Z-axis towards another variable.
We use separate texture atlases that loads into an invoked texture offset-function when needed. This way we can animate any non-static sprite at any given point at a low cost.
Basically: `animationSystem.Animate(atlas, tiles, speed, repeat);`
The Animate-function checks whether it's a different atlas than the current one and switches if is. These are already loaded into memory to keep things fast.
We use a sprite manager system that combines all static layers into single separate draw calls. Every layer has their own texture atlas that gets baked into the layer. At start we remove all static tiles and let the sprite manager take care of them instead. This keeps us in about 20 draw calls for the current frustrum scene whilst not having any serious impact on fps.
We use a game manager to keep track of the current level, score, music and other settings that functions as the overhead for the game. This manager follows the game from start to end.
Basically: `DontDestroyOnLoad (this);`
Time and effort
I'm the only programmer and we have one graphics artist and one sound engineer. We all have other jobs on the side but we're about ready to construct all levels for the game, create menus, scoreboards and finish up after one month of nightly development.
The sum is that, Unity has a great way of dealing with 2d-games as long as you think 2d the whole process. It's more of a camera- than platform-issue.