* Would you have to install through the app store gui?
With various linux package management systems you have multiple interfaces to the same same system thus you can at one moment use the gui to install foo and having closed that you can fire up your favorite terminal and run install bar.
* It'd clutter the app store and force developers to use the app store and whatever approval process they decide.
It also has a concept that neither Microsoft Apple nor Google has opted to pick up on because they desire control of their platform and to extract a substantial tax on all software sold on same via such control... sources also called repositories.
Linux package management systems draw from not a single centrally managed source but a user editable list of sources. Each source is free to run with their own set of requirements. There is nothing requiring a hypothetical dev tools source from being any more restrictive than whomever maintains the source used by homebrew.
Further packages can actually contain sources. It would be entirely trivial to package up a source of dev tools as a package and allow people to install that via the front end of their choice.
* How would it handle different shells?
Different shells is probably the simplest answer the arguments to a hypothetical install command would be simple text strings. If the argument command includes characters that the shell considers special characters they would have be escaped or wrapped in quotes like any other combo of shell and cli tool. Generally most package names just don't include characters like ([])$\~`'" in the name and most commands don't require any particular special attention to shell escapes.
* How would it manage dependency chains and conflicts (system ruby vs local ruby)?
* How about explicit paths or build parameters?
These are implementation details that don't go away by exiling developer tooling to officially unsupported channels. For example language specific package managers will probably remain a thing but it would be vastly easier if you could do officalmacpackage install developerrepo then officialmacpackage install cargo|node|whateverfloatsyourboat then use that to deal with whatever.
All your concerns are basically lack of experience with more reasonable systems there are zero good reasons not to do this. There are literally no downsides other than the work required for an official solution. However it seems vastly unlikely that we will ever see such a thing.
The logical endpoint of Apple's vision seems to be 2 classes of device. One with a very high introductory price and annual maintenance that allows you to create and run whatever you like so long as such software is distributed via blessed channels and you tithe the required 30% to apple and more reasonably priced but still expensive devices that only allow you to consume software.
The former will come with xcode and technology to deal with apple approved languages. You will be able to play with other tech on your local devices but it wont be able to be distributed to end users.
The latter will be as open as your ipad is now.