All JITs use self-modifying code, and JITs are more popular now than even 15 years ago. Although you might make a distinction between modifying code that has already executed once, from the perspective of instruction/data consistency on a CPU it doesn’t really matter.

1) Yes, cache, though it was specifically the introduction of split instruction/data caches. Modern processors are basically Harvard architecture internally, handling instructions and data separately to allow them to be processed in parallel. So either explicit instructions (RISC approach) or extensive tracking of cache entries (CISC approach) must be used to ensure that data cache changes are propagated to the instruction cache.

2) It greatly complicates things in terms of software engineering. It's bad practice unless strictly necessary. Code that rewrites itself is very hard to debug, trace and just generally work with, compared to immutable blocks of read-only code. Most high-level languages don't expose anything except function pointers in terms of self-modification, so compiled output would rarely need SMC. (Though it may be faster to emit SMC to implement high-level constructs, in some edge cases.)

The hardware doesn't like it and maintainers, managers, and most professors don't like it, either.

I still used it on a 486 in the mid-nineties in drawing routines to switch the drawing mode without having to have a dynamic function call in the inner loop (or having to duplicate the drawing routine for each mode).

I think it was the Pentium that introduced split instruction/data caches on x86.

I think the Linux kernel has some limited forms of self modifying code?