> If you use an "int", you have specified that it must be at least 16-bits wide.
Few people write code for PCs with the assumption that an int could be 16-bits wide. They all assume that it's going to be 32-bits at least. A generic "int" encourages bad assumptions. Then come beasts like "long" or "long long", and people must pull out compiler manuals, talk on support forums, and so on. A developer is obliged to do that, but system integrators and cross-team reviewers are in for a world of pain if they have to keep reading across code bases across platforms like that. It's not an unrealistic scenario. A modern airplane or electric train is bound to have tens of processor families littered throughout the vehicle.
The original commenter also wrote about Swift going backwards, with its UInt8, Int32, etc. I'm not a Swift programer, but the documents gave me the impression that these are, again, syntactic widths, not physically allocated, i.e. semantic widths. All this shows that the original commenter had a problem with specifing any indication of the size of integers. His emphasis on "word-sized" clearly indicates that he wants to use "int" everywhere, and hopes the compiler will take care of the rest. This is what Swift does too with its "Int".