Sometimes difficult is just a euphemism for not being a mindless drone that always does what it's told.
Then you have the issue that the new people you hire might be worse AND a huge pain to train. Or you spend 3 months getting them to know your system and then they leave for another job.
At some point people know if you don't care about them. If you cannot care about them why would they "follow you into battle?"
That's true, but it also works both ways.
If the "problem" person is impacting others on your team, you owe it to them to address rather than ignore the issue. After all, why would _they_ follow you into the trenches if you've shown that you don't care enough to deal with an issue that they're saying is making their lives difficult.
(Good) management is about striking a balance - between the business's needs (otherwise you're all out of a job anyway) and the welfare of everyone on the team (which IMO, should always benefit from a bit of priority over the other).
Sometimes that does mean making a hard decision about someone who's very technically capable, but damages the wellbeing or efficiency of the rest of the team.
As an extreme example - I once worked with someone who was a pretty good engineer and knew where a lot of the bodies were buried in the codebase (i.e. keeping him around would be beneficial), but one day he started regularly talking, quite inappropriately about schoolgirls in the team skype group (and even defended doing so). Good engineer or not, sometimes things have to change.
All of that being said, I think the article is too hardline, at least if those are intended to be the opening gambit. There's a ton of people engineering that you can do before you need to reach the point of making it sound like a PIP.
So I'm no stranger to the whole thing. There has to be something coming back from the team members and if they essentially don't give a stuff and treat the rest of the team like dirt then I don't care how great they are - I don't want them.