Shouldn't the client give the user control over how many times it can divide an input? For example, one might not prefer to divide their 0.01 BTC into 5 worth of 200,000 sat each, because it's more expensive. And I did experience it as well, if you want some feedback; I felt as if I wouldn't know beforehand how much money would be spent on the transaction fee.
The client is only able to calculate its output decomposition after the end of the input registration phase, so it's not possible to do this manually with precision. But yes, the "slot machine" aspect can be frustrating if overpaying fees bothers you.
BTCPay Server's coinjoin plugin allows power users to choose a minimum denomination amount, exclude certain denominations, etc so they can avoid surprises.
Is there any particular reason why taproot addresses are preferred over segwit?
You're not going to like the answer, lol. It's a bug: The ratio should be ~50/50

If you find the source of the bug in the code and open an issue accurately describing it, I'll award a 50k sat bounty. If you open a PR that fixes it and gets merged, I'll award a 100k sat bounty.
Isn't it less block space efficient?
Taproot is
barely less efficient than segwitv0 when measured in vbytes, but it's much more efficient in terms of actual bytes. If the witness discount multiplier were slightly lower than 4, then Taproot would win out in both categories.