The main reason why this isn't very feasable at the moment is due to tx id malleability (as the ECDSA signature is included in the tx id and the same tx can be signed with a different valid signature because ECDSA approach used by pretty much all Bitcoin wallets includes a "random" number).

The introduction of SegWit gets rid of this problem by removing the signature information from the tx (it is provided separately in a "witness block") so once this is in place it will be possible to make the sort of bandwidth size reductions you are suggesting (and that is planned).

That's not to say that such an approach couldn't be used currently - but it could be susceptible to attacks whilst the tx id malleability issue remains (there are other advantages to removing the malleability as well which is why SegWit is higher priority at this stage).