Problems that *could* be done with substr, but are not trivial as in your example. Also, "superior" ne "purely faster".

If it requires loops and ifs around the substr, it is surely faster to write and debug. Execution would depend on how much and how fancy you need to be. The OP problem, for example, is nearly trivial with a regex, but you'd have to pay me money to write as a set of substr()s.

"Usually" is certainly debatable, and I expect that it strongly depends on your environment. Personally, my code has a ratio of maybe 1:99 substr:regex. Filtering to what could plausibly be done with a set of substr, I'd guess it could be brought up to about 50/50, but the code would be horrendously brittle and scary. And I'm pretty sure my implementation of the search and matching would not be as fast as the regex engine.

If you are always dealing with fixed width field data, substr becomes more useful and common.