It is a well known performance issue to minimise the traffic between browser <-> internet <-> application <-> DBMS.

The question is how much is being saved in total, where it is being saved, and at what cost. Especially considering built-in compression, i am not sure you are saving too much.

Your belief that anything can be done in SQL, surely cannot reasonably extend to pre-empting data entry mistakes?

Actually, with common mistakes, it most certainly can. As long as the mistakes are finite, and can be flagged as mistakes and what the fix is, there's no reason any mistake needs to be fixed manually more than once. With the amount of data you are processing, it most certainly makes sense to do it all in the database, and only ask the user for input where a new mistake pops up. Plus, by doing it in the database, should there be a service disruption, the state is saved and the data need not be transferred a second time, saving a lot of work from the user. Implementing it in the UI likely means restarting the process any time anything fails, and allowing zero collaboration, whatsoever.