I believe that the approach in chriddyp’s post you link to is essentially the same as the Multi Page app approach described in the Dash docs. They both use Dash’s support for single page app by associating a callback to the current URL, which injects the appropriate layout for the URL that has been navigated to. chriddy’s post showed a way of extending this idea to have the URLs associated with distinct modules. This is really just a way of organising the one app into different modules. While they look like different apps, they all share the same single Dash instance (and therefore Flask server).
The difference between a multi-page app such as that, and going the emperor mode option is that in the former you have a single app running on a single Python instance (ignoring multiple workers etc for now) and in the latter, each is an entirely separate Dash app running on a separate process. Which is better probably just depends on your needs. The emperor mode option will make it easier to keep things fully modularised, with your separate apps being able to be maintained and deployed independently of the emperor mode scenario. But maybe you actually want everything to run in the same Flask server/on the same process, in which case the multi-page app might be the way to go (if performance is a concern you can also use multiple workers (optionally threaded) for whichever wsgi server you’re using).
I’d imagine that if you thought about it a bit, you could also enhance chriddyp’s approach to either use a parent Dash instance or spin up a new Dash instance depending on some deployment configuration, giving the multi-page approach the flexibility of deploying the modules independently. Actually, in which case, you could probably use the same setup to run those modules/apps on emperor mode.