Let\'s say we are designing a new system and have decided to use MongoDB as the primary database. The data schema is very similar to a blog with [growing] comments.
To add to what Thilo said above, the reason to "not embed fields that have unbound growth" is because this type of document size expansion can cause MongoDB to have to move the document if it exceeds the current space allocated to it. You can read more about this in the Padding Factor section of the documentation.
Those types of moves are relatively expensive, especially if they happen frequently. Therefore limiting the size (essentially bounding that growth) of the comments equivalent in your main collection (most recent X etc.) and perhaps even pre-populating that document field (essentially manual padding) to reduce the moves caused by comment additions/changes may well be worth it for you.
Mongo sounds like it would work fine for you guys, just keep the "comments" in a separate collection ad opposed to a sub element of another document, i.e. a page (continuing the blog example).
As for Mongo's performance, as long as those indexes can fit in ram you should be fine.
You could stick with MongoDB, but not embed all the comments into the main document, but just the most recent ones (limited by number), and keep all the rest in a separate collection.
Your main problem is that you are then probably making updates and deletes to data in different memory pages which means you won't be able to update as sequentially. In this instance, many databases will have the same problem so switching from MongoDB won't solve anything.