I just can't bring myself to believe there is a meaningfully sized group of developers that have considered the performance of text-wrapping.

You're kidding, right? There are a ton of non-trivial edge cases that have to be considered: break points, hyphenation, other Latin-based languages, etc.

From a Google engineer's paper describing the challenges: https://docs.google.com/document/d/1jJFD8nAUuiUX6ArFZQqQo8yT...

    Performance Considerations
    While the `text-wrap: pretty` property is an opt-in to accept slower
    line breaking, it shouldn’t be too slow, or web developers can’t use
     them due to their performance restrictions.
    
    The pinpoint result when it is enabled for all web_tests is in this CL.
    Complexity
    The score-based algorithm has different characteristics from the
    bisection algorithm. The bisection algorithm is O(n * log w) where n is
    the number of lines and w is the sum of spaces at the right end. The
    score-based algorithm is O(n! + n) where n is the number of break
    opportunities, so it will be slower if there are many break
     opportunities, such as when hyphenation is enabled.
    
    Also, computing break opportunities are not cheap; it was one of
    LayoutNG's optimizations to minimize the number of computing break
     opportunities. The score-based algorithm will lose the benefit.

    Last 4 Lines
    Because computing all break opportunities is expensive, and computing
    the score is O(n!) for the number of break opportunities, the number of
    break opportunities is critical for the performance. To minimize the
    performance impact, the implementation caches 4 lines ahead of the
     layout.
    Before laying out a line, compute line breaking of 4 lines ahead of the
     layout.
    If it finds the end of the block or a forced break, compute the score
     and optimize line breaks.
    Otherwise layout the first line from the greedy line breaking results,
     and repeat this for the next line.
    The line breaking results are cached, and used if the optimizer decided
     not to apply, to minimize the performance impact.
    
    Currently, it applies to the last 4 lines of each paragraph, where
    “paragraph” is content in an inline formatting context separated by
     forced breaks.
    The Length of the Last Line
    Because the benefit of the score-based line breaking is most visible
    when the last line of the paragraph is short, a performance
    optimization is to kick the optimizer in only when the last line is
     shorter than a ratio of the available width.
        
    Currently, it applies only when the last line is equal to or less than ⅓
    of the available width.
    Checking if the last line has only a single word
    Checking if the last line has only a single word (i.e. no break
     opportunities) requires running the break iterator, but only once.