Strictly speaking, no, In theory you should only register a debug event with a non-system administrator (unless, as you mentioned, you need other system accounts to have direct memory access to other computers).
I however do take issue with the idea of this paper (And although its bias, I frequently take issue with SANS advice on any number of topics).
Just so I can summarize the paper to everyone who may read this who isn't already familiar with the attack, It goes something like. "You can grab GUID and/or Access Tokens from memory or the network and use their hashed value without ever knowing the original password". They go on to say that common ways of doing this from a limited account include crashing a service that uses SMB/NetBIOS credentials then immediately trying to register CREATE_PROCESS_DEBUG_EVENT and voila - Instant access to the appropriate users SMB share.
For those of you who use hashes, This is probably a pretty obvious attack and is certainly not new.
My issue with this is - Why? Why would an attacker go through all the hassle of grepping through memory for a hash after crashing (presumably) a system-critical service. If an IPS isn't triggered now - The NOC sure is.
Theres hundreds of easier ways, ARP Poisoning, False BPDU manipulation, OSPF Area-rerouting, even using source-route info, All fantastic ways to intercept MS-CHAP or SMB information. As well, privilege escalation vulnerabilities are dime a dozen on NT, Seizing access tokens from a specific application is comically easy.
Ultimately, From where I stand, You're way better off using something like Kerberos or RADIUS, Provided that kind of infrastructure isn't available - NTLMv2 which has more complex Challenge/Response algorithms which cannot be man-in-the-middled without privileged knowledge.