Having a method that is only called at one place is ok, if you want to tidy your code (except that that hope is long lost in this project). But if that method usually returns an array, except if it's an empty array, then it returns null, but at the only call location you handle that null case specifically to act just like it would if you just had returned that empty array in the first place, then I ask myself: Why separate that?

The inner method could have been crafted first and intended to be reused.

The dev could have been trained to follow some OOP best practices, including keeping individual methods small.

The dev could have been following best practices and interested in separation of concerns.

The dev could have been a martian.

No idea man... It can be hard to figure out what another dev was thinking when all you have is their code. From what you're saying though, there are legit reasons for such a setup.

If that developer really wanted to follow best practices, then it's like ironing your clothes during the apocalypse. Many classes have a three digit number of class variables that are just there to not have to hand them over from method to method, there are fileWriters that never get closed, JavaDocs are complete crap in 99% of cases (like "@param string The string"), multiple people have their autoformatter turned off all the time (so that 90% of changes I see in commits are just formatting), often there are checks for null when it can't be null or when it can only be null, or no checks if it actually can be null, I just saw calls to "check[...]AreTheSame([...])" and "check[...]AreNotTheSame([...])", both aborting the action, because they actually mean something completely different, ... So yes, it could have been best practices, but if you want to do that in this project, you could just do easier stuff. Like autoformatting everything or looking at the list of 400.000(really)warnings.