Microsoft
Microsoftrjmcmahon Please keep in mind that I am in support, so the article is support slanted.
From a Microsoft supportability perspective, we need internally trusted tools like ntttcp and ctsTraffic that we (Microsoft support) can use for troubleshooting purposes when addressing networking issues related to Windows and the Microsoft ecosystem.
The tools mentioned in the article are built by people on the Windows core networking team and are used to validate the operating system and certain interoperability scenarios between Windows and other platforms. They are built by people who know networking and the Windows network stack inside and out. They are made available for public use by Microsoft so we (Microsoft support) and our customers can test knowing that the tool is built using our own internal best practices and recommendations. If something doesn’t work with our tools, then we have a good idea something is seriously broken.
This does not remove nor diminish the need for third-party (non-Microsoft) based tools. Native tools like iPerf2 are welcome and encouraged.
These tools serve several important functions. They can confirm Microsoft's own results and alleviate concerns about cheating. Something that has been mentioned by more than one person in this comment section and across the Internet. Let's face it, no one will ever 100% trust a massive company like Microsoft.
But, most importantly, people need tools that can validate their own needs and scenarios, and the Microsoft tools may not provide those capabilities. Our tools are built for our needs, but our needs are not everyone’s needs.
While iPerf3 is an excellent tool for the platforms it natively supports, and in certain capacities with community supported versions for non-ESnet supported platforms, the fact that it is not purpose built for Windows diminishes its usefulness in an official troubleshooting capacity for the reasons outlined in the article.
Does that help clarify things the article’s stance?