The bottom line is that MongoDB and MySQL are two different persistent data structures. MySQL is a more powerful data structure that can do more things. MongoDB is less powerful, but is more efficient at certain things. Due to pre-mature optimization or shortsightedness, some folks are romanticized with the efficiency of a less powerful data structure (MongoDB) and fail to realize that their application really need the more powerful relational data structure.
These things should be good learning examples for all.
This also makes it sound like whoever intervened to rewrite said feature in sharded mysql had an easy time. Usually this would not be an obvious port. However we don't know the technical nature of the feature or specifically why it failed.
I'm the developer that helped migrate the data from mongo to mysql (under mcfunley's supervision). Even a straightforward data migration becomes complicated when you have to do it without affecting the production feature or consumers of your public api (parallel writes to both dbs, snapshot and move the historical data, switch reads to the new db, etc). In addition, we took the opportunity to move the feature to a sharded architecture and to rethink the schema. Anyway, you're right in that it wasn't exactly an obvious or easy port.
Congrats then! I've seen mongo features start simple then end containing a bunch of embedded lists of primary keys to SQL or other data stores, rather than what would be a bridge table or two. Not as elegant if your not putting everything there (as some people here say here is mandatory to prevent the overhead running mongo on top of everything else like you mentioned