Eh, that’s a quite wide question, since scale can mean different things and different things become concerns depending on your definition of it. I.e. FB has to cover a lot of markets and everyone is the target user, including low-end devices with slow processors, low storage and low amounts of RAM. They operate an all dimensions of scale. With hundreds of modules and a huge app, having just 10% size overhead might cause a huge drop in installs (it can be 10-20-30-300mb) difference. Since this is mostly a dex count optimisation, shaving just 10% off the final dex size can increase user acquisition by a small percentage, which is potentially worth millions of dollars in FB’s case. Compile time here is a smaller tradeoff (yes, it will impact it but caching + fresh builds are done on a CI) for the final app size reduction. It might also reduce your app’s startup time due to the multidex impact, since this way you can avoid it.
But for some other apps, scale might mean performance optimisations - i.e. trading apps where speed is of critical importance, and there you might require some other optimisations that would try and “primitivize” data classes, due to the performance impact instatiation has. On some other apps, you might hit the problems of scale as in the amount of data, which requires different optimisation points and you gotta be careful of complexities. Meanwhile, somewhere you only care about a high-value target market and the scaling problem is more oriented on “how can the codebase scale for the amount of developers we have”.
I’d suggest as a manager to find the biggest pain points that impact your app’s performance on different levels - your team’s performance (readability? build times?), your app’s performance (from startup to logic to UI) and user acquisition performance and your target market’s constraints (memory?speed?storage?data?), and then the calculation of “is it worth migrating” becomes way easier - time x money to implement vs time x money saved.