Some use cases of transient storage EIP-1153 that work best with the transaction-level version of transient storage (rather than transient storage just for subcalls, which must use callbacks):
ERC20 temporary approve: approve a spender for a single transaction
Why not EIP-1363 approveAndCall? That requires the spender to support a callback or an intermediary contract which is more expensive and does not work well for approving multiple tokens
KYC: call a kyc contract to verify your identity, and then call other KYC-gated functions on other contracts that also check you’ve verified your identity in that transaction. This might be used with transient storage because you only want to prove your identity for a single transaction (rather than associate your identity to the account for all time, including e.g. after loss of a private key)
NFT royalties or ERC20 fee-on-transfer: pay a fee to unlock transfers for that token ID or token amount for a single transaction. Other designs of FOT or NFT royalties break composability, e.g. fee on transfer tokens may take fees either from the recipient or the sender balance. This avoids the breakage due to transfer fees. Also allows fees to be paid by a third party or in a different token.
If you propose everything should be a callback, you get callback hell. Imagine you want to temporarily approve an ERC20 to pay some NFT royalties to accept an offer on a KYC-gated NFT marketplace. Or, imagine that you want to approve 3 different tokens and then call into a contract. Both require 3 separate callbacks. How do you order them, and how do you construct calldata for passing through the several callbacks? How do you verify callbacks all came from the right contracts? Callbacks should be avoided unless necessary, and it’s not accurate to say all these use cases are supported via callbacks in the subcall-only transient storage version.