I would say this approach is for situation where the model you're using isn't always applicable. In the case of this article, it's discussing teleport, a drop

I would say this approach is for situation where the model you're using isn't always applicable. In the case of this article, it's discussing teleport, a drop in replacement SSH server. For many users, this is their administrative connection to a fleet of servers (teleport can operate as a transparent bastion, as well as on the end host). So in our case, it's a desirable feature to not interrupt existing shell sessions, while replacing the software serving those connections. This could mean the admin's own connection to the server doesn't fail mid-upgrade, or that hundreds of internal employee's don't groan because whatever they were doing that used a shell just got dropped and they need to restart. Disclaimer: I work with the author of the original article, and contributed to the article.