To a first approximation, never. There may be some generic collection algorithms which can make good use of indexes and operate on strings just as well as other collections. However, if you're using string indexes directly, assume that there's some better way unless demonstrated otherwise.
The idea is that you (or, even better, standard library authors like me!) build more useful algorithms like filter and dropFirst that internally use indices, and then ideally don’t have to mess with them directly after that. Of course there are always cases where you’re doing something unusual that isn’t covered by the available algorithms, but we hope as we continue to expand the toolbox, these will become increasingly rare.
I wonder, at what point did this become the status quo? Forgive me my forgetfulness, but I am quite sure that at a certain point in the past — although I can't quite pinpoint it at this very moment — I used to read that Swift's String indexing model is fine and its use certainly wasn't discouraged.
Also, Strings created in Swift are always UTF-8, but on Apple platforms String may be backed by a UTF-16 NSString, where indexing into the UTF-8 code units is not an O(1) operation. (And I think most of String’s design was done when Swift strings were UTF-16 by default as well.)
If you don't mind slow index operations (including accidentally quadratic algorithms in case you, say, go through each character of a string and do a subscript with integer index) then consider this simple wrapper. This might be ok for tests and short strings, just avoid using it in real apps in production.