I doubt he meant that third-party developers' hands were tied. I think he means that Microsoft spent incredible resources on backwards compatibility at the expense of innovation. To take the most extreme example I can think of: going from OS 9 to OS X, Apple preserved a (comparatively) handful of APIs as-was, another pile as nearly-the-same-but-requires-modification, and regardless of which they temporarily preserved, made it very clear that you were going to completely rewrite your application if you intended to have a genuinely native OS X experience. By contrast, farking Microsoft OS/2 apps survived into Windows NT 4, and Windows 3.1 apps ran from 1993 through some forms of Windows XP without blinking. Even in the hated Windows 8, Microsoft went out of their way to make sure that they maintained very clear and well-spelled-out migration paths. It is theoretically possible (though you'd be insane) to write a WinRT app in C that mostly uses kernel32.dll, if you want to, because WinRT is unapologetically based on COM, which is in turn based on an old way that vtables happened to be laid out in VC++, which is in turn based on how C structs used to lay out function pointers. This hurts WinRT performance compared to what they could've accomplished with a Swift-like linker.

Did this insane focus on backwards compatibility hurt Microsoft? I don't think you can conclusively say. Did it hurt me as a former Windows developer? Only at best tangentially; all the backwards compatibility crap is pretty abstracted from you if you hang out in .NET land. (Except when it isn't.[1]) And at any rate, I don't think the bleed-through is noticeably worse than e.g. POSIX intrinsics showing up in OS X. But I think the argument that the engineering required to ensure Windows maintained such a strong backwards compatible stance ate out of resources that could've kept Windows more up-to-date has a point.

[1]: http://bitquabit.com/post/zombie-operating-systems-and-aspne...