sorry but I'd say it's pretty empty post

- you come to contradictions because from one hand you are saying about following standards rather than preferences but then you point out things like "aren't complex too understand", "good names"... hahaha.. in real projects with real complex tasks you either should have so detailed standard that nobody could ever possible to write and support or you should rely on someone's opinion and preferences

- whether solution is solving the problem or not isn't possible to figure out during review for tasks more complex than println("Hello world"). For that goal there is a QA team. Don't mess things up.

At the very edge case following your paradigm you have to deploy this code and test it in order to make sure it works

- code review is very important for

a) code owners to check if the code follows his/her preferences/ideas/intentions... if you don't have code owners I'd say code review is only 50% useful

b) teammates to be aware of what's going on in the team and for sharing expertise. Of course, the most explicit code issues are revealed (like code format although for that purpose formatters are better choice)

c) for managers to keep the illusion that everything is under control and code is perfect

so, long story short my point is that you either have a code owner and it's up to him/her how to code review or you have some poor outdated standards and code review is done by all teammates between each other based on these standards but don't expect any objectivity here (at least knowledge are shared within team and it's not bad)