Consider a transaction that has 2 inputs and 1 output. Let's say that the inputs are both 1 BTC and the output is 1.5 BTC. This would mean that the transaction pays a 0.5 BTC fee, which is ridiculous.
Consider a hardware signer which has no idea of the blockchain's state, but it still needs to know those input values in order to display to the user before it signs the transaction. Let's suppose the hardware signer has a more efficient protocol where the host provides the transaction and just the UTXOs (the scripts and amounts) that are being spent.
If the host were honest, it would provide the transcation and the UTXOs spent with their correct amounts. The user would see that they are spending 2 BTC and throwing away 0.5 BTC as fee, so they would reject the transaction.
But what if the host were malicious? Suppose the host instead provided 1 UTXO correctly, but the second UTXO has the wrong amount - 1.500001 BTC instead of 2 BTC. Now when the hardware signer shows the user that they are sending 1.5 BTC with a fee of 0.000001. This would be a reasonable transaction so the user approve the transaction and it would be signed and sent. But what they actually signed was a transaction that sent 0.5 BTC to transaction fees.
With non-segwit scripts, the above scenario is possible, so in order to protect against it, hardware signers require that non-segwit inputs provide the entire previous transaction so that the transaction id can be calculated and compared against the transaction id given in the spending transaction. This guarantees that the amount is correct as if it were not, the transaction id would be different. But this can be a lot of data, and so it is not efficient.
However with segwit, the amount for a given input is signed, so it is not necessary to provide the full previous transaction. In the malicious case, the user accepts the transaction and the hardware signer signs it. However when it signs it, it commits to the amount of the input, and so it would commit to the wrong input amount of 1.500001 instead of 2. When this transaction is broadcast, nodes will validate the signature and find it to be invalid as they would be using the correct input amount of 2. Thus segwit prevents this attack from working.
...Except not completely. After segwit was deployed, we discovered there is a way bypass this. Suppose the malicious host is able to convince the user to sign the same transaction twice - perhaps after the first time it claims there was some error and the user needs to try again.
In this scenario, the host can provide the correct amount for the first input and the incorrect amount for the second input for the first signing attempt. This would produce a valid signature for the first input, and an invalid one for the second input. Then it prompts the user to sign again, and this time it provides the incorrect amount for the first input, and the correct amount for the second input. Now the malicious host has a valid signature for the second input too. It can combine those two signatures and produce a valid transaction which has the transaction fee of 0.5 BTC.
With this new attack scenario, some hardware vendors decided to require the entire previous transaction when signing segwit inputs as they do with legacy inputs.
But there is a solution for this second issue which Taproot solves. The solution is to commit to the amounts for all of the UTXOs being spent. Instead of just the amount for the particular UTXO that the signature will be in the scriptSig for, the amounts of all other UTXOs will be included in the signature. This means that changing one amount will result in all of the signatures in the transaction becoming invalid, so this new attack cannot work. Just for good measure, Taproot also commits to all of the scripts of all UTXOs as well.
