I found something interesting at this X3J13 issue.
According to quote in hyperspec, it looks like your example is unportable code, since the spec clearly says:
The consequences are undefined if literal objects (including quoted objects) are destructively modified.
You code is quoted, therefore it is considered to be literal, even though it comes from non-constant data. The spec also states that compile-file is allowed to coalesce or copy constant data. The same is not true to eval or compile, but compile-file could be used to implement the REPL, therefore potentially bringing those issues to the REPL, but now this is a hypothetical example, since it is stupid not to use compile or eval instead. And, even though the specification restricted the copying and coalescing of data by the compile function, Kent Pitman said that at least MCL coalesced data when compiling code. But that was back in 2001, now there is no MCL anymore, but I think this justifies what he was trying to say.
Anyway, as I usually think, the REPL is an informal tool, you can and should do with it whatever you want to do without any harm with an implementation you trust (for instance, SBCL, which would warn you when you are doing something potentially dangerous). If something goes wrong, you can find the error, learn from it and try again in a different way or report it. But when writing files which you will distribute, you should to be careful with constant data.