I can see that. There are plenty of cases that certainly would not work, e.g. in a Python block it would be a mistake to run a command that sends the buffer to the interpreter! In the example I provided, you can see I also had to "preserve" a few org-bindings so you could still do C-c ' to get to the special edit. If you didn't know what was happening, it might also appear that certain org-bindings you were used to had stopped working, e.g. I have a lightning fast muscle memory to export a buffer, but it doesn't work when in a src block with this modification (unless of course it is "preserved" in the keymap). Whether this matters is up to the user, since they get to choose how the keymap is defined. I would expect it defaults to the org-mode-keymap.
On the other hand, there are times when I am working on a document that has a lot of short code blocks, e.g. for lecture notes or blog posts, where it is sufficiently tedious to me to switch in and out of the special edit mode that I wanted to try this solution out, and it became clear you can't really try it out without modifying the core org code that does the font-locking on a block.
I don't think we have to go so far as to say we make multiple major mode keybindings available, so much as context specific keybindings available where there is value in it. We already have this in org-speed keys for example, and even these can be context specific to do different things on headings (even different things on headings with specific properties) and blocks (
http://kitchingroup.cheme.cmu.edu/blog/2016/12/22/Context-specific-org-mode-speed-keys/).
If there was a change to org to enable this, I wouldn't expect the core to change behavior for anyone, it would just make it possible for users to change this if they wanted to. The same way they can customize the face of a code block for different languages.