The thing that RHEL is trying to fix is to prevent customers from being tied to the system python/perl and should install a version that works for them and the application they are trying to run. People installing random modules into the same perl/python as is used for system startup/critical software has always been a problem but it is also one of those things that makes having a long term LTS nearly impossible because you can't separate the user needs vs. the distribution needs and trying to fix anything turns into backports to weird ancient versions. This way distros can package and update the things they need independently from everything else and not disturb the user, and also provide a more comprehensive suite of packages that also don't disturb the system space. This is similar to how Amazon Linux is setup a bit.

A better example is a user I should be able to install python 3.7 and use it, even if the system libraries for the core packaging is based on python 2.x. Traditionally most users would just build their system scripts on python 2.x (because it is there), which means that if you upgrade the distro from RHEL X to RHEL Y (which brings a python 3.x) you break a user's environment. This was a constant problem when you were trying to go through the RHEL 5-6-7 upgrade paths among other things.

It hopefully will be resolving the issues of people and packaged software using weird old versions because it is there and breaking when something changes. My favourite example is having to write in ancient bash just to support MacOS which still ships bash 3 something.

In a shorter version, the interpreters are still there and buried, just not on $PATH and given to the user as a what they should use.

(This is opinion based on how I have seen people abuse systems and try to upgrade them over the years).