The article talks about how this makes them more effective as a team because they suffer less pain with integration and merge conflicts. This makes me think they are working with a very poorly organised code base, or as a team don't practice use of interfaces/contracts effectively. If they inherited a code base from someone else, then it may be largely unavoidable, but if it's always been their own code, then in my mind it's a bad smell.
I have been working on a project for 2 years with a team that is 7 developers which is in on time and the client just finished their final testing today with no significant bugs left outstanding. As a team, we were almost always able to each work independently on tasks due to early establishment of good patterns and architecture as well as regular design sessions for upcoming work by our two most senior team members. Each team member would typically push their SCM (Git) changes up to several times a day and merge conflicts were rare and practically always easy to solve. We even changed to better patterns 4 months into the project and due to good layout of our code, we could run the new patterns side by side with the old ones.
So how did we largely avoid stepping on each other's toes? Code was properly arranged so that areas of concern were appropriately isolated. When working on a front end use case, the only area of contention was typically registration of a module, after that all your code would be in its own independent area which no one else was working on. If it was a large use case with lots of screens, one developer spends 20 minutes stubbing out the code layout, commits, pushes to Git, then everyone else pulls and goes on their merry way. If use cases need to interact with each other, then one developer ensures the interface is correct, which may involve a 10 minute talk with a fellow developer, the interface is immediately updated and pushed into the repository and again each developer goes back along their merry way.
You may have noticed me mention that we push quickly into our repository, the article mentioned developers trying to merge a week of work and that terrifies me. If code is properly isolated, then your work can be incomplete, but not affect the existing working code, or other people's work in progress, so you should push *at least* once a day. If you need to alter an interface on your side for a colleague, but you were in the middle of something and weren't really in a position to push your code, then you: Git stash, update interface file, stub out implementation file if needed, push, then Git pop, you can carry on and so can your colleague. Additionally, our CI environment (Jenkins) is building and running tests on every commit, if someone pushes something that breaks the build the whole team is notified and it's fixed within 15 minutes.
Another comment has already mentioned that the quality of code would be higher with the team approach, but in my experience, as long as the code is reasonably efficient and more importantly, easily understandable to anyone else looking at it, improving quality beyond that in most circumstances adds little to no real value for our client. Since easy to understand code is mandatory, in the event it needs a bug fix, or in the rare case it needs to improved, perhaps for performance reasons, it's not especially hard for any developer in the team to do so.
Of course it will be different working on our code in 2 years time from now for ongoing improvements, but as we have been doing for the past two years any time we feel our process isn't working well, we will discuss it during our regular retrospectives and adjust our process to cope with the problem, could that process result in team programming like in the article? Possibly, but I highly doubt it.