I think it's less for tracking than for trying to combat viruses and phishing attempts. Having the spool data and writing the JavaScript mail client app makes link-based tracking redundant.
It's not the bandwidth per se, so much it's the continuous attention cost spent on keeping that bandwidth going.
Better tactile feedback and more reliable input means I don't have to constantly multitask half a task worth of attention onto making sure the input I think I'm doing went off as intended, which makes it easier to concentrate on the main task, which reduces the build up of fatigue, which reduces the rate at which the cost of mental effort increases throughout the day.
Which is not to mention things like the chance of getting hand cramps from the additional tension there caused by interacting with a less reliable keyboard, and by the tendency to use excess input force in attempt to get strokes through more consistently.
Contracts state a lot of things that don't necessarily hold up. It's just words on paper. Sometimes they're even tenable in one area, then used in another state which disallows some claim or another.
Employment contracts in particular are subject to a lot of restrictions and protections regardless of what the employer makes people sign, because labor laws.
RHEL is popular for solutions like running a datacenter mostly because it has a nice enterprise support story. It's what the E in that acronym is for, after all. Ubuntu, meanwhile, is quite popular among us mere mortals who have to fix our own boxen.
Debian is popular for Docker images exactly because many of the people trying Docker were already familiar with Ubuntu. Those users quickly ended up wanting smaller images, making Debian an obvious thing to try out since Ubuntu is basically Debian with bells on.
Ubuntu fought a sea of distros and came out as what's very nearly an industry standard, if not an official one. The 90s were a fricking mess by comparison. Slackware on floppies.
(And now I need "Slackware on floppies" dubbed over the "Jesus wept" scene from Hellraiser.)
It's faster, but only under the specific design condition of both having to wait for storage to finish and not caring about differences between the presented storage options.
If the design condition allows asynchronous operation and I don't need to wait for background tasks to finish before I reply, it's not faster unless I somehow care more about background CPU time per request than I do about things like storage guarantees.
If the design condition requires durable storage to have happened before I reply, putting it in Redis doesn't even count as getting started.