You mean there's a problem with static var? Inline value is just a magic constant without name and for me it is harder to reason about code locally.

I should use there private static. I could use instance fields if the kata was instance based, but that is not the case.

I wonder if CPU and time overhead of pattern is worth few kilobytes of memory.
String#split does not compile Pattern at all, if it detects regex contains only non-regex characters and fus should be slightly softer on CPU (but performace test are needed).
I think Pattern#splitAsStream could be used as readability argument, but in terms of overhead, I would not consider as performance optimization.

StringBuffer is way slower than StringBuilder, because it is synchronized. And if nowadays you see StringBuffer anywhere in single threaded code it is archaic (or poorly written) code.
BTW code from kata with +="" whould compile to StringBuilder concentrations, very inefficient ones however.

Also in Java 9 there is one big optimization in terms of String concatination, that is using invokedynamic bytecode code, but still it is not even close to raw StringBuilder implementation as seen in discussion on SO:
https://stackoverflow.com/questions/49458564/string-concatenation-in-a-for-loop-java-9/49466784
(javap -c bytecode text included)

Thus: string concatination is optimized in trivial cases, but in loops they are still to be optimized by hand.

But on the other hand: it is good practive to make your code universal and you have char[] array already created. It just needs to be extracted to a variable and iterated with = instead of +=.

+= in loop creates string.length + 1 String objects. Better to use StringBuilder or byte/char array

Without mutating object it would way easier. This one is more chalenging which is good in terms of Kata as programming challenge.

From my point of view, Kata is a given problem you have to resolve with code, not code you have to fix.