Of course Code Review isn't needed. Then again, neither are tests, continuous integration, source control, customer involvement, profiling, static analysis, decent hardware, one-click builds, bug tracking, the list goes on.
Along with Code Reviews, the things I mention above are tools that help ensure software quality. With a combination of skill, luck, time and determination; you can deliver quality software without any of this stuff, but it's more likely that you won't.
In your scenario, there is nothing to be confused about. Not every organisation indulges in every best practice. They may disagree with it, it may conflict with a different best practice that they do implement, or they may consider that the overhead of implementing it is too great for them at this point in time. Depending on their circumstances, they may be correct in doing so, or they may be making a false economy. For some tools, (e.g. source control) the payback/effort ratio is so good that using it is a no-brainer; for others it's less clear.
There is no doubt that code review is a practice that introduces a significant overhead. Because of this, organisations will seek to minimise that overhead, either by not doing it at all, or by only doing it in certain situations (e.g. for a junior team member, or a particularly hairy change). It is not always obvious that it pays back more (in catching bugs, reducing technical debt or sharing knowledge) than it costs. Most of that payback is difficult to quantify, whereas its very easy to count the number of man-hours your organisation spends doing reviews. The easiest bit to quantify (reduced bug count) is easy to attribute to other factors (e.g. "of course it has fewer bugs, it's more mature").