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