If you did as you propose then the 'address' would be less 'address' like, and more a combination of both 'address' type information and 'spending mechanism' type information, the latter being the locking script code.
'Address' means 'location' of some kind, whether it be Bitcoin address, memory address, IP address, or a person's home address. In Bitcoin this location is the source or destination of funds, and it is convenient to have a notion of 'address' in this manner, and it helps non-technical people to grasp the basic concept of Bitcoin I think.
When we started out with P2PK type outputs the 'address' just encapsulated the public key, which 'locates' the person (or group of persons or machine etc) with the unique corresponding private key.
Then with P2PKH came a level of indirection with a hash of the public key now being used, but again the 'address' thus formed was very 'location' like, and uniquely identified 'someone' (or some other entity which can hold funds).
However when it came to P2SH, 'spending mechanism' type information entered the 'address' because the address then contained a hash of the required locking script. It's yet another level of indirection - the 'location' of funds, ie public key hash, is now stored in that implied locking script. The address thus now includes both 'address' type information and 'spending mechanism' type information, as in your proposal. Thus you are right - a Bitcoin address can ALREADY include scripting type information that pertains to 'spending mechanism', as well as containing 'location' type information. Thus the 'orthogonality' of these two types of information has been lost to some extent with P2SH.
Furthermore some 'orthogonality' is lost by P2SH in that there is no longer the clear distinction of the scriptPubKey containing only locking script, and the scriptSig containing only unlocking script. The scriptSig now takes the form of the unlocking script FOLLOWED BY the serialized locking script. And 'spending mechanism' is changed to a 2 stage process consisting of first checking the locking script has the correct hash, then subsequently executing the unlocking script concatenated with the deserialized locking script.
BUT in the case of P2SH this is a worthwhile compromise because P2SH is a powerful mechanism of great convenience which allows anyone to easily send to such a 'location' which uses a complex locking script, using only a standard sized Bitcoin address starting with a '3' and to not have to include that long locking script in the transaction (which would increase the fee).
So P2SH bends the orthogonal angles down a bit somewhat - though for a worthwhile reason. In all designs there is trade-off and compromise - losing some desirable property in one sense may be worthwhile for a powerful benefit.
In your proposal the orthogonal angle is being bent down quite severely - 'addresses' which are encapsulations of 'location', and which are used not just within Bitcoin itself, but everywhere where Bitcoin transactions are taking place, now carry along with them this additional scripting code, which is the detail of 'spending mechanism' rather than 'location'.
This is not a water-tight logical argument - but to me it seems the more 'elegant solution' to keep Bitcoin addresses storing the smallest amount of 'location' information and let the transaction creators deal with the actual scripting code details.