There is a spectrum between style differences and absolutely unreadable code.
If it is absolutely unreadable, sure, send it back to be readable. But if it is merely styling issues, I'd encourage you to understand that you are not saving any time by focusing on styling before functionality.
Far more developer time is spent reading code than writing it.
If you can speed up the time required to understand a piece a code by improving the style then it's almost always worth it. For a professional software engineer, just above "absolutely unreadable" is far too low a bar to aim for.
Imagine a developer building a PR for 2 weeks, then reviews back and forth for 2 more weeks. Now 4 weeks have passed and only now the reviewer reviews the functionality - only to find that the entire implementation is wrong/could be done in a better way.
What a waste of 4 weeks of both the author and the reviewer! This could have been short-circuited very early in the process.
On my team, we default to early feedback on functionality and let the CI enforce what it can. Everything else is debatable.
1. Review functionality and then
2. Point out something about coding style.
In fact, if the functionality is good, I even approve the PR leaving a lot of code styling comments that the author can fix at their own leisure.
It's about clearly and concisely expressing ideas.
Leave styling to linters. Reviewers should be focusing on how the code is communicating.
So the first priority is getting the change to a readable state. I'm not talking about nits, I'm talking about minimizing the cognitive overhead to truly understand what the code is doing.
That being said, it is also easy to identify nits during this phase. In codebases that have collections of best practices, this often helps to ensure that the change is expressed in terms of a common vocabulary. Once this pass is done, the reviewer can usually better understand the intent of the changes.