(Not that I’m claiming to know your code base or specific challenge or anything; I’m just speaking generally)
I have some firmware on a small machine, there aren't any arrays with more than two dozen elements. On the eight bit machine the the code originally ran on using a 16 or 32 bit int caused a lot of code bloat. You might not think that's a problem but consider the price difference between a processor with 64k of flash and 128k might be a dollar. Times 100,000 units a year.
The above is why I'm not going to use rust anytime soon, because a rust binary size is about 4 times larger than C. That would add about $2-3 to the cost of the product. Or $200-300k a year for no real benefit at all.
The criticism isn't even specific to exotic environments. The same reasoning applies at bigger widths too. I've certainly used `u32` in places instead of `usize` to avoid doubling the size of my heap use on 64-bit systems.
Implicit widening would be nice, but it isn't necessary.
A lot of times the code size doesn't matter. In my case it's important. Consider a lowly printf statement in my firmware.
It takes about 120 bytes of code. A trivial amount! Lets see how much that costs us.
Marginal cost of flash is about $1.00/64k. So 120b/64k X $1 = $0.001875 per unit.
We ship 100,000 units per year.
So that printf costs $187 per year.