Well, yes, it is a bit
However, I'm deliberately not blaming the Microsoft technology in-and-of-itself. The built-in design assumptions that are now failing those protocols, are exactly the assumptions that were sensible to make, at the time they were first developed, over a decade ago. (True, the complete lack of effort, by the vendor, to update them is what lies at the heart of quite how awful it is, of course, but even the best efforts would not have addressed the core of the problem. I really don't think any completely stateful networking protocol makes sense, over such ranges.)
This is why I made my fairly flippant, but entirely valid, point about HTTPS web-based systems being used as a quicker and more reliable means of data exchange within the business. There isn't a strategy dictating it's uptake; there's just a need.
One of the reasons we still connect to some of our machines using PuTTY, here at work, is that an established PuTTY session will always keep responding, even when the machine it is hosted on is completely frozen. Since this Dell laptop can freeze for upwards of ten seconds if I accidentally click on some HR share, that I don't have permissions to (while it relays this message back to me, from Vienna, or Madrid, or wherever), the temptation is to proceed with the assumption that what you are using is a truly "multi-tasking operating system" and try to give it something else to do while it waits.
This id a Bad Idea, since it completely jams up it's buffer, with extraneous requests for work, that its hasn't the processing power to cope with. Its task priority was built for an age where a simple permissions message didn't have to cross mountain ranges and great stretches of sea water, just to tell you "you can't come in". And Microsoft are the world's great optimists, of course: they always prioritise the displaying of error messages right to the top of the pile (as I say, where I work, even our bollox-ups have to undertake journeys that would make Bilbo Baggins flinch.)
So we learn to just switch to one of the PuTTY sessions and get on with something more productive in the mean time. We have two or three screens, as standard, anyway, so you just request some action from the Windows box, that will cause some visible change on one of the other monitors, when the queue finally clears, and in the meantime you get on with something more useful in the PuTTY session.
Ah yes, green text on a black background. Welcome to the twenty first century: please form an orderly queue... However, if the damn machines themselves can't task-switch with any grace, then I guess we'll just have to (I've become much better at marshalling myself, than I ever was in C++).
Ultimately, this points to hardware hypervisors, and Chrome-like operating systems, of course. But I restate my point. The problem isn't the Microsoft: it's this whole "desktop operating system" thing, which is failing us. The relaying of computing work backwards and forwards - when all I need to see is the outcome - is where the waste comes in.
This isn't the future, of course; it's the past - since it's just a dandified version of the old client/server mainframe world. However, if it makes me more productive, because my productivity falls back to below the levels of the machines I use, then I'll be happy.
(Our motto at work is: "You wait around for ages because the bus-errors arrive in threes".)