Downsides: indexing into a string isn’t O(1). To find, say, the 200th character in a string, you have to go through the string data from the start.

So (not Swift, nor, AFAIK, any other existing language)

  for i = 0 to stringlen(s)
    print s(i)

would be O(n²), so slow for long strings. It’s rare to have code that accesses the n-th character of a string without accessing all earlier ones, though, and idiomatic code

  for c in s
    print c

can be efficient (not as efficient as iterating over fixed size units, but not dramatic, either)

Also, requiring String to know of what code points in Unicode are “combining” means carrying a few tables around in the implementation. That could be problematic when porting Swift to devices with small amounts of memory. It also, I think, ties Swift to a version of Unicode. You cannot predict what code points in future versions will be combining characters (https://en.wikipedia.org/wiki/Combining_character)

I also think there are a few corners where Swift doesn’t reach the goal of “a character is what naive users expect”. Ligatures in Unicode might be problematic. For example. “fl” is a single Unicode code point, but, ideally, would be two characters “f” and “l”.