I'll reply to myself, because I discussed it with Bitcoin devs at #bitcoin-wizards (freenode IRC), so they shouldn't waste their time replying here too.
The issue with that simple suggestion indeed appears to be along the lines of what I suspected it to be. From the point of view of programmers who are responsible to deploying the protocol, it may still make sense to simplify and use only NTXID, i.e. to compromise and lose some of the expressive power that Bitcoin scripts allow. There could also be other options, such as attaching the signature (for the implicit message of the entire transaction) outside of the ScriptSig input-script.
Fortunately, we can indeed get rid of transaction malleability with a softfork that keeps the current scripts infrastructure in place. The thing that I missed about NOOP operations w.r.t. malleability is that the ScriptSig input-script (that doesn't get signed) doesn't really need to contain executable opcodes, only data. In other words, if the user can redeem an unspent output by providing a witness w that satisfies a circuit (script) phi(w)==true, then it's too general to require that w can be an executable circuit in itself. If I understand correctly, this sensible restriction is specified as new rule #4 at
https://gist.github.com/sipa/8907691