MeshBatch is more of a optimization technique, it's like a DisplayObjectContainer but for objects that most of the time will remain static (will not move, rotate, scale), so AddMeshAt should be the same as AddChildAt - only for setting a Z-order (order of drawing of objects), nothing else, as far as I understand. It has nothing to do with tilemaps directly, it can just be used to optimize performance, tilemap performance as well.
As a best example - Starlings TextField with a bitmap font is a MeshBatch itself and its letters are Meshes (Bitmaps). You can do most of things with TextFields, but when the're not changed during frame, they do not redraw, so using less calculations/resources each frame they do not change. The same with MeshBatches, as TextField is a MeshBatch.
As far as I remember, I'd used large in size MeshBatches with a height or width of several thousands of pixels with thousands of meshed (children), where each mesh (Image/MovieClip) was relatively small, and it worked fine (as long as using Texture Atlases the right way) and noticeably improved FPS. I've used them in mobile games on iOS/Android.
There were only few issues I remember:
1) in the process of creation of thousands of images, game freezes, so I would advice you not to create or erase everything in one frame, but create and destroy/dispose smaller chunks during runtime.
For ex. it's rather better to create thousands of data-only objects of where an what object will be, but create graphics for them only when they will be drawn in the near future. You will greatly save CPU time (in the time of loading, by redistributing calculations to the frames throughout gameplay) and RAM and will avoid small freezes when level/game loads. The best practice is to Dispose objects after (if no longer needed) or remove them from parent (and add via AddChild again when needed). A bit worse is to just toggle their visibility as object will still exist in the loop and eat some small CPU time. But even without those optimizations, GPU should draw only visible objects, it should be more of a RAM/CPU issue.
2) a single MeshBatch has a max number of children, so before adding Mesh to it, always check with if (CanAddMesh(xxx)). If MeshBatch is full, just create a new one.
3) there are many potential problems with redrawing MeshBatches on iOS while app is minimized, as iOS does not allow drawing while app is inactive, so you might have troubles/headaches with them when app will be minimized. Be very aware on async calls (calls to server) which will have callbacks/responces that will redraw your meshbatches, as when callback is triggered when an app is minimized, and that callback draws/redraws some MeshBatches, you will have an exception. Use Starling Juggler delay calls where you can, not setInterval/setTimeout.
For DisplayObjectContainers, it seems that Starling itself resolves this issue.