It is always up to the wallet client to decide which UTXOs are to be spent. The protocol certainly doesn't require all UTXOs of an address to be spent at the same time. A particular wallet client could be coded to do that, but I don't know of any that are.
Here you can see a testnet example. Transaction
90d042b... spent only 2 of the 9 UTXOs available in address
moooopfhBjQDSJQuCj4aVr6s4b5pFbQin4. This transaction was created with just the ordinary
sendtoaddress command in Bitcoin Core, no special options.
This isn't a significant security risk. In a secure digital signature protocol, it should be infeasible to generate a valid signature without access to the private key, even if the public key is known. That's what "public" means! As far as we know, ECDSA is secure, so revealing the public key doesn't harm security.
Some people believe in planning for the possibility that an attack might someday be found on ECDSA. If so, then there would be some advantage in not having revealed your public key. After a new signing algorithm is incorporated into Bitcoin, you could create a transaction sending your coins to an address which uses the new algorithm. This would reveal your public key and attackers could get started, but assuming the attack is fairly computationally intensive, you hope your transaction would be confirmed before an attacker could successfully create a forged signature on a transaction that would send your coins to him.
The tradeoff of this approach is that, as you note, as soon as you want to spend any coins from an address, you have to spend all the UTXOs. This increases the size of the transaction and thus costs you more in fees. That's why most clients don't do it; the security improvement is theoretical at best, but the costs are real.