They aren't saying "don't let the clients do anything", they are saying "don't trust the values the clients send back"
If the client messes up the rendering, the only person affected is the client. There is no 'trust' required, because you are not relying on anything the client has done.
The idea of trust only comes into play if there is a consequence to that trust being broken.
When somebody says "Never trust the client" inevitably somebody will find a use case that sounds like trust even though it's not what they're saying here and use that as justification.
The lack of nuance is how things like "never use stored procedures" gain traction when they shouldn't.
No, just google "wallhack".
the server sends to the client: account A has $100, account B has $200, make your transaction.
1. trusted client
client says: i've done my transaction, now account A has $50 and account B has $250.
the server updates the database accordingly.
client says: i want to do a transaction from account A to account B with 50$.
the server decreases account A by 50$ and increases account B by $50 and updates the database accordingly.
client says: i've done my transaction, now account A has $52 and account B has $252.
the server updates the database accordingly.
they try to do server checks to prevent this, but due to network timing problems they can't check the exact values, only calculate if this is maybe approximately right.
so a players maximum running speed is, say, 6m/s. they could do periodical checks (every second) if the player moved more than 6m since the last second. but what if the player falls down a building or is thrown by an explosion further than that? it'd register as cheating, even though it's completely legal to jump off a building. so they have to increase the checks for distance/s by 3 to allow those situation (i.e. 18m/s). a cheater with a modified client can now continually run three times as fast as any other player without getting flagged as a cheater.
why do they do this? because it's
a) easier to implement (the client has to do all the computations anyway - doing them a second time on the server and then sending back to the client isn't an easy problem - you have to interpolate) and
b) cheaper (less work = less man hours, less complicated work = cheaper programmers* and less server power needed)
* i'm completely sure the devs would have been 100% able to do it right, but it would have taken them longer, thus costing more.
so, how to fix it? there's only one way: rewrite the model. but this is expensive and the titles have already been sold, so why bother investing another couple hundred thousand bucks? even the disgruntled gamers will buy the next ubi soft title if it's shiny enough. i mean, few people will buy the game now that multiplayer is infected with cheaters but they already exploited enough of the market and long time players are probably less likely to buy the next title if they're still playing an old one. maybe.
What you're also implying is that clients should do no processing - because clients can't be trusted to do anything. If you apply this logic to web-browsing, you're asking the server to send the client a bitmap image of what the rendered page should look like.