There are some aspects of that concept that are sometimes implemented today, there are other aspects that are avoided.

Keeping teams small is one of the basic features of Agile Methods, but is also practiced outside of Agile.

Cross-functional teams are also a staple of Agile, but common outside of Agile as well.

The role of the Program Clerk is largely subsumed by computerized systems such as Version Control Systems, Software Configuration Management Systems, Change Management Systems, Document Management Systems, Wikis, Continuous Build Systems with Artifact Repositories, and so on. I mean, can you really imagine paying a full-time employee to print out source code, and manually index and file it?

Similarly, the role of a System Administrator (not part of Mills's Surgical Team, but part of a typical cross-functional team of the last years) is being obsoleted by concepts like DevOps (absorbing the role of Sysadmin into the role of Software Engineer), Platform-as-a-Service, Infrastructure-as-a-Service, and Utility Computing (making the role of Sysadmin "someone else's problem"), or Infrastructure-as-Code (turning System Administration into Software Engineering).

One of the aspects that we try to avoid today, is that at most two people understand the system. Only the surgeon is guaranteed to understand the system fully, the co-pilot may or may not. This gives a bus factor of between 1 and 2. If the surgeon gets sick, the project is dead. Period. The Agile answer to that is Collective Code Ownership, which is the exact opposite of that model: nobody is singularly responsible for any part of the system. Instead, everybody is responsible for everything as a group.

Lastly, there are some assumptions baked into that concept, which are outdated. For example, even though it is not stated explicitly, the team is set up in a way in which only one person in the team (the surgeon) actually has a computer. That is, of course, because at the time the article was written, even the idea that an entire team would have one computer for themselves, let alone one person on the team, was a stretch. (Even in 1980, when Smalltalk was released, one of the things that contributed to its failure was the fact that the system was set up such that every developer and every user had their own computer – completely unthinkable at the time.)

So, in short: I don't think the concept has been implemented exactly as described, but some aspects of it definitely are implemented, some aspects are seen as undesirable and actively avoided, some are obsolete, and some are Probably Good Ideas™, but nobody does it.