sigh Please, Please, provide reasons along with your arguments. Simply stating something doesn't help, especially when there is contradicting information floating around.
That being said, it's likely the firmware's failsafe-mechanism kicking in when it cannot access the memory chip that stores the password (because access to the chip is hindered).
Yet utilizing the "WP" (write protect) pin on the memory chip ought to do nothing in my opinion - unless the firmware tries to store something to the memory at boot time (which is entirely possible). On the other hand, forcing clock or data pins to ground - in effect disallowing any signalling via them - should be a sureproof way to force the firmware to trigger it's failsafe mechanism.
But I was more interested in the end-to-end test, as I expected others reading would also be:
SDL to SDA (the usual instructions given elsewhere) only works on some models.
PROT to GND appears to work on all. In my collection of ~ 30 machines, it works on all the models SCL to SDA does, as well as all the models SCL to SDA does not.
PROT to GND was the original hack as discovered around the time of the T20.
Source: http://cache.nxp.com/documents/data_sheet/PCA24S08.pdf (Section 6.4 Access Protection)
PROT is not the WP pin. They're different. Go read the spec sheets.
The original hack as discovered was PROT to GND, not SCL to SDA. My only speculation was as to why the hack as reposted changed over time.
The more interesting aspect, verified by testing, is that it does work.
In my own testing, SCL to SDA will not work on the T2X, T3X, T4X, T60, X2X, X3X, X4X, or X60. It does work on the T61/X61 and T400/500.
PROT to GND works on all of the above. I also tested it on an X230 (works), but I didn't check SCL to SDA on that machine.