It's not just instructions - it's CPU bug workarounds, too. For example, some 386s did not honor the write-protect bit in the page table when in supervisor mode. Now, since Linux normally does copies from kernel to userspace by writing straight to userspace and letting the WP bit detect writes to read-only memory, it's a problem if the WP bit doesn't work (it'd let you overwrite write-protected userspace memory). So Linux had a check that tested (at boot time) whether WP worked properly in supervisor mode, and if so it would set a flag to perform a slower, software-checked copy. This adds overhead to _every_ copy from kernel to userspace, as it needs to check this flag, and branch to the fallback implementation.
Or you know, use a flag. And if it becomes a performance issue later on after some profiling, consider a more complicated approach. Don't underestimate your CPU's branch prediction.
Self modifying code is a can of worms. Many things can go wrong, and good luck debugging the mess.
This is all resting on the assumption that the flag does actually have an impact, which was an argument in the original comment.
As for self-modifying code, the dangers are way overstated IMO. Having written a lot of it as well as reverse-engineered and debugged code using self-modifying code heavily, I look at it as just another tool in the chest. It's pretty easy to chop your limb off using self-modifying code, but having audited a whoooole lot of static code, I'd say that argument applies to just about any tool.
