First, most people do not need to use dtrace. Especially on system processes. They claim that this is bad for security researchers because they can't monitor the system anymore and they showed a screenshot of dtrace not working even with SIP "disabled". However, from the screenshot, we see that SIP is, in fact not disabled because of this line
> System Integrity Protection status: enabled.
You can see here http://internals.exposed/blog/dtrace-vs-sip.html that with SIP properly disabled, you can run dtrace on system processes. Yes, it's confusing that it says "DTrace restrictions: disabled", when it should say "some dtrace restrictions".
Also, no security researcher worth their salt would be stopped by this (and no "bad guy" would be stopped from debugging either). In fact, dtrace is only a convenience and one tool in a toolbox; you have VMs with kernel level debuggers. You have object code analysis. You have wireshark and so on. If Apple can't stop people from jailbreaking their iphones (where hardware enforces the lockdown), they won't stop people from debugging their PC's kernel.
Basically, SIP is good for users (the "Ultimately this means that Apple has replaced the 'be all and end all' security barrier of the root password, with the 'be all and end all' SIP protection mechanism." argument is the same as "we shouldn't outlaw guns because people will find other ways of killing each other") since it makes compromising a system all that harder. If it hinders ANY security research, I question the skills of that researcher.