This is true. You only have to deal once with a device that doesn't have a light or something to realize just how essential indicators are. I have sworn to the electronics gods to never to make a device without at least a power led.

I use mergerfs to pool a bunch of varying sized drives and then run snapraid on the whole pool to protect it. Then, I've got Kopia backups running and backup up to a remote repository. This solution has been flexible and I've already been able to recover from 2 drive failures very quickly and easily.

Less biased than some other media sources I've seen and makes it more likely that I'll read it. Since the opinions are clearly marked it's possible to skip them as well and just read the facts as presented. I just keep it in mind as I read and it works for me.

It's the best one that I've found since the old ES File Explorer sold out and became adware

I don't think so. It might have been delisted as I don't see it either. Regardless, it's OSS so you can get it from the GitHub repo. https://github.com/hidroh/materialistic

Assuming that there is at least some amount of slippage between the wheel and ground, it seems to me that you'll need to regularly check the ToF sensors anyway. I've found that encoders are fantastic for a lot of things, but not so much for measuring distance because of the problems you've described. Perhaps a recurring local check on a reduced set of points to verify location then forward the full cloud less often for further remote processing? It really sounds like you have a tradeoff depending on whether you value accuracy of location or accuracy of wheel rpm (analogous to speed). Using both would give you a nice way to calculate the ideal motor rpm to minimize slippage in a surface agnostic way.