If anything, null-terminated strings are bad for performance as often as good for it. One example that comes up reasonably often: comparing strings that have different lengths but common prefixes is fast with length-tagged (Pascal-style) strings, but expensive with C-style strings, because you have to scan both strings until you find either a string end, or a difference. So instead of quickly answering "not equal" after one integer comparison, you could end up doing hundreds (or thousands) of byte comparisons in degenerate cases. Anything that calls strlen() also ends up doing extra work.

Well, as far as kernel is concerned strings aren't a problem. Outside VFS they don't exist. Inside VFS everything is chopped into usually short pathname components which are hashed for dcache consumption. On x86_64 hashing is not byte-by-byte anymore.

Fixing pathetic macro system and type system (if that qualifies at all) would get rid of many many bugs.

It affects performance more on old, register poor, slow CPUs. Memory latency dominates processing time now, but it used to be a real issue.

Sure, but we always had the option to switch off bound checking on the code spots where it really made a difference.