If it's so trivial to implement then where is your proposed implementation and BIP? It could be re-implemented fifty times through rejections and objections and still be less work that the true work associated with all the testing, wallet implementations, and alt-implementations associated with this idea.
Anyway, it doesn't simplify offline signing all that much, it just makes it possible with more limited hardware. The actual code is basically the same in both cases. Heck, the design effort required for the hardware isn't much different in most cases: moderately fast USB interfaces aren't a big deal these days and come pre-packaged.
This also encourages the design of really limited hardware wallets that don't support the payment protocol: if you don't know who you are paying, all you've done is limited the rate that your funds can be stolen a bit. Heck, on that basis I think I'd actually NACK such a patch myself...
It definitely simplifies offline signing significantly. With the proposed modification, the HW wallet only has to present the user with a prompt to confirm sending X coins to Y address with Z fee using some number of wallet addresses for which it has the private key. If the transaction that the device is being asked to sign is not what the user expects (including the case of large fee), they reject it. Simple.
As it stands now, the HW wallet has to be able to prove without a doubt the current value of its wallet addresses so that the fee can be properly calculated and presented (or to trigger an auto-reject if the fee is above a threshold). This requires tracking and verifying a large enough chunk of the blockchain to prove this. What's the lightest way a small HW wallet can do this without trusting the SW feeding it transactions to sign? It's something I'm researching right now, but the proposed modification would make this problem irrelevant and cut down development and testing time significantly.