In the worse case, this algorithm makes k iteration and creates k brand new string objects. Not the most efficient approach.

Multiline lambdas with curly braces and functions that aren't pure (i.e. functions that cause side-effects) are not considered a good practice.

To begin with, I didn't tell that any method must have exactly one return statement.
For maintainability reasons method has to have AS FEWER RETURN STATEMENTS as possible.

'Object.equals() method uses multiple return statements'

equals method in the Object class has only one line that checks reference equality. Basically, it is entry-level information that you should know by hard.
Most of the classes in the JDK and different frameworks override default implementations of the equals method to define equality based on an object's state.

For the purpose of explanation, I think equals probably is not the best illustration because it is short and simple.
To describe a method that has more than one exit point but still remains to be well-readable let's consider a method, which implements some intricate algorithm, and may be it's a relatively long one. And it has the following structure:
{
if (eliminate one case) throw ... // that's the early kill and that's great
if (eliminate another case) retrurn ... // and that's the early kill as well

// MAIN LOGIC

return ...
}

To conclude, in general, return statements in the middle of a method has to be avoided where it's possible.
Because it can create confusion when return inclosed by multiple loops and conditions, as well as when return statements are present in both try and catch blocks.

DISCLAIMER: I don't say no one writes like that. I say it is considered to be undesirable nowadays.

Quick digression. If you think that JDK is written by the Gods and there are no pitfalls in Java you have a lot to discover.

'how you would solve problems of that kind in general'
In terms of clean coding, it's a naive way of thinking that there's some kind of uniform recipe that can be applied anywhere.
Clean code - is a code that is EASY to read, but difficult to write.
There are tons of books on this topic and if you expect to receive an exhaustive unambiguous answer in this comment then I'll say:
Sorry silver bullets are out of stock))

If you want to see how to solve this kata in an imperative way without exiting in the middle of the loop take a look at my fork.
That's doable with a help of break statement or labels. Caution, both of them can make the code cluttered, and labels are actually discouraged to use for that reason.

By the way, your dubious attitude to streams is still unclear to me.
Streams are effective, lazily evaluated, very nice in terms of readability, and capable to solve most of the problems which traditionally were implemented using loops.
If you are striving to write clean then code functional style is more preferable over imperative. And that is the strongest suggestion in my answer.

Now you are free to ignore this information or explore it father on your own. I hardly can add anything.
Good luck.

If it was a replay to my comment can elaborate on your thought. I'm not sure that I've understood correctly what you are trying to convey.
What is the connection between import statements and best coding practices?

Apart from the weird formatting multiple return statement is not a best practice.

Do not use valueOf() methods of wrapper types when you don't need an object, use parse instead.

'It always begins and ends with an uppercase letter.'
This requirement contradicts the tests. To avoid confusion I suggest removing it.

'When the packet doesn't have only uppercase letters and spaces or just spaces the result to quicksum have to be zero (0)'
From this statement, it is unclear if blank string (consisting of white spaces only) is valid or not.
I suggest considering rephrasing the requirement or adding a test with a blank string.

This recursive call after both strings are already processed is not a very performance-wise thing

if(f2.length < s2.length)
return interlacing(s2, f2);

Doesn't meat with the single responsibility principle on not being very maintainable.

This solution is faulty, it could return null instead of proper result.

For instance given the following array [-3, 3, 5, 9, 1] - it'll stumble on the first pair of elements, break out from the loop before reaching the element with a value of 1 end return null.

Concise but not very clean and hardly can be considered a best practice.

Good point, but you are basically using the same approach. Hence the time complexity of your solution isn't perfect as well.

That code will return true for any string with multiple dots like this "8...1.9."

No need to perform sorting if the given string has a length greater than 26 (i.e. there will be some duplicates).