Smart Contracts: Why even brother asking for ERC20 approval, if it can give itself the approval anyways?

I was writing my first smart contract interacting with ERC20 tokens and I realised one thing:

While, for the tokens I work with, I need a token allowance to have the smart contract be able to spend it, I realised, that my smart contract could also simply just itself invoke the ERC20 approve function and give itself the allowance it needs to process my tokens.

While this may be convinient for my smart contract, I think this is highly problematic for the smart contracts in the wild. I mean, doesn't that mean, that as soon as I interact with a malicious smart contract, that it can simply give itself ALL approvals for the most common tokens and thereby drain the account? Is this the reason, why people say "don't interact with smart contracts"?

Do I understand this situation correctly?

Not only is this problematic, but this also actually completely negates the whole purpose of the allowances. I mean, why does uniswap even brother to ask me for an approval and make one swap into two tx (approve + swap)? If I have to trust uniswap anyways to not make a malicious token approval call, then they might as well just approve the amount for the swap and execute the swap together in the same tx. Right?

What do you think? Am I missing something?

If this is really the way I describe, wouldn't it be necessary to implement guard-checks on the msg.sender side? Concretely, It would make more sense to have some kind of account-side function approval, where an account itself can specify, whether a certain function of a certain contract can be called by a smart contract or not. I could then say, that e.g. only Uniswap even can call the approve function of a token and any other contract attempting to call it would immediately revert. I think this is not implemented in the ecosystem and would need to be an EIP... right?