2) Use tools to enforce style if you care. Personally, I think it's a waste of time.
3) If you have devs merging code to trunk that isn't fixing the bug and creating the feature requested, then that devs needs replacing.
RE unit testing: I realize it's not that widespread. But anyone developing software and not unit testing is doing it wrong. They should take all the time they waste on code reviews and instead spend it on building out their test suite.
And unit testing Javascript is not only possible, but easy. We do it with Jasmine. It works great. The key is to write good, testable JS instead of the mess of spaghetti that passes for Javascript code in most places.
This is a very good point. If there are very basic things not being done (or done well) focusing on those things is more important than ceremonial code-reviews - and in the beginning it seems code-reviews are often only ceremonial and some shops never get past this stage. I've never seen them work really well aside from cases where they happen organically between two co-workers who like and respect each other.
Woah slow down there soldier. Code reviews are great for many reasons:
1) Introducing new technologies or techniques you used to solve a problem.
2) Letting your styles mesh with your team.
3) Focusing on whether the concern/problem has truely been addressed.
Also, unit testing isn't as widespread as you may think. Many of the projects I've worked on didn't have the infrastructure in place to even start unit testing. Also, ever try to unit test Javascript in the browser, it's possible but it sucks pretty hard.
If you are on a team of 2-3 hardcore devs, then you're probably more correct than not. Thats not usually the case.