This argument is much worse than "we should have made functional programming the standard back in 196X" (which might some merit but overdone imo). The Harvard architecture is just a hardware separation of instructions and data - the argument is virtually an urban legend. Hardwave code/data separations are relatively easy, have existed at time but change nothing since dynamic language just makes its code into data and the self-modification is unhindered.
see: https://www.computer.org/csdl/magazine/an/2022/03/09779481/1...
Separating the call stack (and probably inventing a very specific "the only valid reads/writes in this area are the ones made by the CALL/RET instructions" permission bit for it) from the data stack would make almost all buffer overflows useless for taking over the control flow: the normal STORE instruction simply can't overwrite the return address, period.
Of course, the interpreters would still be vulnerable, but even for them having separate (and distant) stacks make this particular vulnerability much harder to exploit. And again, a generalized technique having different processor instructions for manipulating differently "painted" memory regions would help there too — at least, it would be there so the implementers of the interpreters could reach for it if they decided to.
In the end, of course, nothing can save you from having a program that insists on literally doing eval(fetch(url=input())), or curl "$(read ; printf "%s" "$REPLY")" | "$SHELL", or something else to this effect.