Yes, here are some links with reasoning:

• PMD linting rule (Java)
• ESLint Linting rule no-param-reassign (JavaScript/TypesScript)
• ESLint Linting rule no-ex-assign (JavaScript/TypesScript)
• Software Engineering Stack Exchange about it
• GitBook about Java
• medium article "Why it’s bad practice to reassign function params"
• Answer on StackOverflow

There is no point in using new String() here. I think you can just leave it away.

I'm not used to Go so much, but in other languages I use it's considered bad practice to change the given parameter variable, because you usually expect the given value later in the method, not a manipulated value. I mean for such a short method it's not a problem, but for bigger ones it is. Is that different with Go?

There is a lot of duplicated code in that. The last 2 lines in the if and else block are identical, so you can just write them once after the else block closes.

What about caracters like ä Ü ó ß は 😈 ܊ ▧ ☂ ☎ ?
There are 137.374 different caracters that can appear in that String. It's hard to put all into an String to check if it is a different character. Instead you can check if the given character is a number.

Why assigning the result to the number variable as it is not read afterwards?

In the Java Version the ExampleTests file does not compile because of a missing closing curly brace at the end.

The imports could be removed. ;)

Instead of toLowerCase() the Pattern could have been configured as case insensitive.

You can remove the s.trim(). Strings are immutable, so nothing is changed by calling trim(). Instead trim() will return a new String object without whitespace at the start and end. Because you didn't assign the new object to a variable it will never be used and will be removed (later by the gc).

Let's not call it "criticism" but "suggestions". Performance isn't relevant in all cases and the increace of performance through your suggestions isn't very high. Often the performance can be increased by other refactorings like calling an database once instead of inside a loop.

if (condition) { return true; } return false; can always be replaced by return condition;

In my opinion the test cases in areaCallTest() are wrong. The leading zeros are removed in the resulting parts in any cases except area only numbers.
"+12 34 567890" will result in: "12", "34", "567890"
So I would expect "034 567890" to result in: "34", "567890"
Instead "034", "567890" will be expected.
Why is there a leading 0 expected?
Why is it not expected in the national number case like "012", "34", "567890" or "12", "034", "567890"?