I can think of 3 things:
1. You can partition an input file at any offsets, parallelize, and adjust partition boundaries to a valid offset independently.
Without the property, parallelization is hard.
This is how mapreduce has been used to process large text files, except at line boundaries.
Now, for this that might not be a useful enough property, given that we already do similar things for newlines, and UTF-8 guarantees ASCII is always recognizable and hence newlines are always recognizable.
2. It might have been more useful in the era of dial-up where we still had occasional corrupted bytes in the transmission.
3. It helps regain sanity if e.g. a background process outputs bytes that get interleaved at the tty. For example, cat a large text file, the write boundaries won't always align at UTF-8 boundaries, then have a background process output get interleaved in an unfortunate way. If it self-synchronizes, it'll knock itself back into sync after a small amount of garbage.