I think what you're missing is that language runtimes typically install themselves globally, and major release versions typically have issues with backwards compatibility. If you install Ruby 3 globally, your Ruby on Rails project programmed on Ruby 2 may not work. Thus, there is a need to be able to install multiple versions of runtimes, and the ability to cause a particular version of a runtime to be used depending on the project you are in. This allows the development team to decide if and when to make runtime version changes.

My team maintains multiple projects that are over 10 years old with a mix of Ruby on Rails and JavaScript. The code base is large, so there is pretty much a guarantee that going to the next version of Ruby or Ruby on Rails or Node will introduce problems. We lock down all the versions for everything so that we don't have to worry a deploying to a new environment (new server, developer, etc) will have different versions and require use to change priority to fix things. Instead, we periodically review our projects for upgrades, find upgrade issues and fix them, lock new versions, and deploy. Some of the code base is in legacy status. It does what it needs to do, and we have no need to change it unless some security issue is found.