At the same time as _NSAKEY, there was another bizarre mechanism in the '90s called "server-gated cryptography". US law was that exported cryptography could not be stronger than 40-bits, but there was an exception for financial organizations. The implementation was that certain CAs were trusted to verify whether their customer was in fact a financial organization (trusted in the sense that, if the browsers decided wrong, they were violating munitions control laws...) and could place a special extension in the certificate. If that certificate was present, export browsers would negotiate 128-bit cipher suites; otherwise they would only negotiate 40-bit cipher suites.
This mechanism, incidentally, blew up in our collective faces two weeks ago under the name "FREAK", and there was a lot of talk about whether the NSA's meddling was appropriate.
But where's the backdoor? In this case, it is the presence of certain CA keys that allows strong crypto, and their absence weakens it. _NSAKEY has the same goal, but it's just done in reverse. So calling the key a backdoor is not very meaningful, since in the SGC case, we'd have to call the absence of a key a backdoor.
This is a very different sort of thing from the Lotus escrow business in this article, where the software silently encrypts the data to a public key owned by the NSA. The Windows _NSAKEY is just a signing key, and in US versions of the software, _KEY is also allowed to sign all the same things. Nothing is ever encrypted to _NSAKEY.
Or, in other words, the presence of _NSAKEY in US versions of the software cannot possibly weaken anyone's security.
If there is a backdoor here at all, it is the entire system of export controls for crypto. (Which everyone knew about because it was literally the law, so calling it a "backdoor" is sorta like calling Wikipedia's edit-this-page button a "security vulnerability".) All of this was very different from the Lotus backdoor described in the article.