With Distributed Version Control, you don't have to choose
Even if the answer is to "let the Scrum Team decide", that doesn't mean the question is not PM-related, or that no good answers can be provided here. It's perfectly within the purview of a good PM to provide their team with work-flow options that they've found have worked well in the past, or that other teams like. That's the spirit in which this question should be answered.
I think it's a mistake to conflate when to do a code review with when to commit. This sounds like thinking mired in a single-repository, Subversion-type mindset. If your team is using a distributed version control system (DVCS) like Git or Mercurial then these are really two separate issues, or at the very least the trade-off the questioner is worried about is not longer an issue.
In a DVCS, each developer has their own repository, and they should commit there as often as they have a changeset for which they'd like to store meta-data, or be able to revert to, etc., and this is independent of any code review.
The Scrum Team, or any small group of people working on different parts of a single solution, has a team repository. Each developer is responsible for pulling and merging the latest-and-greatest from the team repository into their own before pushing any of their new changes back. Then, when the team decides their set of changes is ready for review, they should push their changes to a code review repository. That way they can continue working (if necessary) in the team repository while code review happens on the baseline in the review repository.
Once the code review is complete, the changes (plus any revisions) are pushed to a stable repository, which is used to construct released builds.
This process enables commits to happen frequently. Commits should absolutely happen prior to the code review, as that's what sets the baseline of things to be reviewed. The beauty of DVCS is that this commit doesn't impact the version of the code from which released builds are made.
This process also solves the problem deprioritizing code reviews, because although the developers have pushed their code to the review team/process it is not yet released. So developers can continue working, but the code doesn't ship until the review is done and the code gets pushed to the stable release library. This should keep the pressure on the review process while not preventing the team from continuing to work.
This process is essentially what's described at the end of the 5th chapter of Joel Spolsky's overview of Mercurial.