Your wallet app (or the dApp you are using) chooses whatever it likes. If you build by hand, you can choose whatever you like.
Often, bills are used as an analogy for UTxOs. While that has some problems (bills are not printed on demand with arbitrary values when you get your change), it is helpful in this case: When you want to pay 15 EUR, you can choose if you use the large 100 EUR bill, the 20 EUR bill or three 5 EUR bills.
Some wallet apps do that on purpose for several reasons:
If you want to submit several transactions in parallel, it is good to have more UTxOs of varying sizes, so that you can use different UTxOs not in conflict for the parallel transactions and they can go through even if the first didn’t already make it into a block.
Before there were collateral outputs with the Vasil hardfork, Plutus contract transactions had to give a collateral input that would be taken completely if the contract fails to validate (to pay the network for the work done in vain). That is nearly impossible to happen in reality (wallet apps, dApps, and nodes check on submission and don’t even let failing transactions go into the mempool), but it has to be in the protocol to prevent malicious acts, anyway. And for that wallet apps want to provide small pure ADA UTxOs with a small amount in them. Hence, they produce 5 ADA UTxOs for this purpose.
If you have NFTs or FTs, you don’t want them all on one large UTxO. That makes transactions very expensive because they all have to be moved everytime that UTxO is touched. But having just one NFT or FT per UTxO locks a lot of ADA with them (since they all need 1.x ADA minimal size). So, wallet apps try to find a sweet spot between that.
In Eternl, for example, you can use “Token Fragmentation” and “Advanced UTxO Management” in the wallet settings to change this behaviour:
If you are using dApps like DEXes, NFT marketplaces, DeFi apps, they build the transactions often not optimal with respect to how you or your wallet apps want to manage it.
On the topic of which UTxOs to take (not so much on which to produce as change on the other end), there is the very old CIP 2 (https://cips.cardano.org/cip/CIP-0002) on coin selection. It specifies two strategies – largest first and random improve – for selecting UTxOs to spend.
Problem is that it was specified before native tokens. Some wallet apps, libraries, dApps still try to use that, but it does strange things if you have tokens in your accounts. Either because of using this or because of using an equally bad home-brew solution, transactions sometimes very needlessly move around native tokens although more than enough pure ADA UTxOs would have been available and none of the native tokens is actually needed for the transaction.
When managing my small accounts by hand, it always doesn’t seem that hard to do the “right thing”, keep a reasonable amount of related native tokens per UTxO, only use them if needed, consolidate same tokens and same policy on same UTxOs, … But I guess that all becomes much harder with really huge accounts (thousands of NFTs and stuff like that) and if there are much less ADA on top of what is needed to go with the native tokens.
Another strategy — as I understand it, carried over from another chain — came along a bit later & is still awaiting a champion to carry it forward as a potential Cardano standard: