Note that the article is referring to NTLMv1 which uses 56 bit DES and, as illustrated by the article, that is easily broken. However, the article conveniently fails to mention that as of Vista and Windows 2008, default security policy requires NTLMv2 which uses 128 bit RC4. That is a totally different crypto scheme. Despite the fact that the protocol for exchanging authentication tokens (NTLMSSP) has been around since early Windows NT days, it doesn't matter - cryptographically 128 bit RC4 is fairly secure. At least the difference between 128 bit RC4 and the 256 bit AES used by Kerberos is not the weak link (and as of today Windows domains still default to allowing 128 bit AES to be negotiated anyway).
Also, note that NTLM authentication is absolutely not obsolete. Kerberos clients require access to domain controllers. Kerberos is very sensitive about the name a client uses to authenticate with a service and it is very sensitive about DNS. It requires a lot of manipulation of principal names and key files. Time must be synchronized on all three machines involved in a Kerberos authentication. Stale tickets may need to be purged. If any of these things are not right, it can be non-trivial to track down the problem. NTLM does not have any of these issues. NTLM is much more robust than Kerberos. It's just less efficient and it lacks features like delegation. A "pass through Kerberos" mechanism is being developed to replace NTLM that would resolve some of these issues (the main one being that clients would not be required to access domain controllers), but I suspect it will still be quite a while before it actually does and it's not clear that it will solve all of the aforementioned issues anyway.