really clever

Good point, there is no necessity to iterate twice to collect the target data.
And could be done with streams API using class IntSummaryStatistics, which fetches count, min, max, and average from a stream in one go.

Pure genius!

Looks cute, but processing whole list two times instead of just once?

The input array will always be valid! (odd-length >= 3)

The solution seems simpler and i was wondering why it isn't voted as a best practice. Your comment made light. Thank you.
Sorting increases execution time. Even for a 7 element array.

exactly

Sort is overkill here. IMO too much upvotes.

Correction: String.join does use the StringBuilder library, because StringJoiner uses StringBuilder under the hood. This means that String.join, StringJoiner, and StringBuilder are all O(n) optimal ways to concatenate strings, whereas the string concatenation operator + is O(n^2).

nCopies just returns a cheap List that contains the repeated element as many times as specified. String::join doesn't even use a StringBuilder, instead it directly builds the char array for the resulting String. It should be hard to optimize further.

In any case, optimizing for speed at the design level would be premature optimization. In production code, I'd expect code that's easy to read and understand even if it's not fully optimized, except when it turns out to drag performance down.

i think you should comment about the nCopies underlying implementation i assume its stringbuilder ! but hard to rate the performance
for called methods from collections without proper knowing how its implemented

HAHA