No, this makes sense. You often see people avoid a good solution in early languages, because it's harder to implement. This impacts security, performance, and overall design.

Consider how much easier it is in rust to do tagged unions that won't have the same pitfalls as C's, how much more likely you are to use a rust map from std rather than custom / imported dependency to do that in C, how much more likely you are to do real Unicode processing in rust vs treating strings as opaque bytes and hoping for the best in C. These are things that happen all the time. We can improve design and engineering a lot by simply providing an easy way to get it implemented.

The first time you need a string map in an existing C code, it's often "an event". Do you spend time rolling your own? Do you include a library? How big - are you pulling the whole glib? Do the strings need fancy locale aware comparison? Do you simplify, take a performance hit, and just scan an array instead?

A lot of the time when there's a logic bug and people comment "that's not a memory safety issue, Rust wouldn't protect from it", it's true, but I also think: "but this issue wouldn't exist because enum/type matching would stop it".

There are two big differences between norms and habits: habits are usually individual while norms apply to a community, and norms have a great deal of social pressure behind them.