The primary purpose of a VCS is not to put stuff in it, but to take stuff out as needed.

Ponder over that statement before you read on.

There is a fundamental difference between how big Corporate IT treats version control vs the Silicon Valley and Startups.

Most Corporate IT teams use version control as Cavemen used fire... just stick raw food in it (just checkin your code into a VCS)!

Silicon Valley understands that fire drives cars, air planes, rockets and, yes, Jetpacks :-) (VCS is the very foundation of DevOps)!

Now this comparison is a little exaggerated, but the underlying point remains. You can use your VCS for basic code checkin and collaboration or you can make it the powerhouse that drives all of your development and operations.

Here are some things you are (probably) not using your VCS for!

Code Reviews

If you are not using a pre-commit code review system, you are not really doing code reviews!

Developers are by definition lazy people (we write programs, so we don't have to do something manually!). An honor/convention-based code review that is conducted at the end of a coding cycle via emails, code-walkthrough, is mostly skipped or given lip-service to. The only effective way of doing proper code review is to stop the developer from finishing the commit, unless the code passes all quality checks and code reviews.

Now, don't confuse code reviews just with manual peer reviews. This is where all the magic happens, from automated static code analysis, syntax checks, build verification, unit test verification etc.

Using a modern version control system like Git with the help of tools like Gerrit, your version control becomes a code review hub with very little overhead for the developers.
Developers use the same workflow that they are used to. For example, here is how a regular commit and a code review request looks like for a developer using Git + Gerrit.

Regular Commit

$ vim file.c ## Make your changes
$ git commit -a -m 'Changed something' file.c
$ git push origin master:master  ## Push directly to the main branch

Code Review

$ vim file.c ## Make your changes
$ git commit -a -m 'Changed something' file.c
$ git push origin master:refs/for/master   ## Push to a different destination to trigger a code review

As you can see there is nothing additional that the developer had to do to create a code review request.

Debugging

Using clean, atomic commits helps you debug when a bug was introduced in the code base very easily.
You can use tools like git bisect to quickly identify when a particular regression was introduced in your codebase, if your VCS has maintained clean history.

Track Developer Productivity

Using Gerrit's changesets allows you to have your developers check-in work-in-progress (WIP) at the end of every day. Then you can report on the activity of each developer across days and months. This is especially useful when you have contractors working on your codebase. Not only can you oversee their productivity, you get all the work at the end-of-day in a central repository.
Here is a default dashboard for a member's contribution from Github.

Github Developer Contribution

Identify Products at Risk

Having a pulse of commits and committers on a repository is a very good indicator of how actively a product in your company is maintained. You can write reports based on the activity on a product's source code repository on whether it is actively supported or not. If a critical product in the company falls below a certain number of active contributors/commits-per-day, that could be a trigger to look into augmenting staff for that product.
Again, here are in-built dashboards from github.com, indicating current product health.

Daily Commit Activity

Contribution History and Top Committers

Commits per week

True Collaboration

Maintaining a VCS that allows a maintainer vs contributor model has tremendous benefit for the IT organizination.
Allowing everyone in the organization access code to the code and submit a patch for review as a contributor, that the maintainers can accept or reject, creates a level playing field across your organization.
Projects benefit from a wide range of people reviewing and contributing to the product and developers benefit by having the ability to expand their horizons into newer products and technologies.

Releases

Instead of developers/build managers doing builds for stage/production, the VCS tags drive your build servers.
If a particular version of your product is ready, you simply tag the version in your VCS as release/3.0.1-beta1 and it triggers your build server to build that version and push it to your artifact repository.
This eliminates developer mistakes of building a wrong version or picking up local changes in the build.
Using immutable tags also makes tracking builds to source control versions very easy, providing very good audit-ability of the releases.
Using digitally-signed tags, verified by the build server, can ensure that only authorized developers can actually release software.
Also, maintaining clean commits allows the build server to automatically generate release notes for each build.

Deployments

Further using digitally-signed tags and a carefully crafted build/artifact server, developers can actually perform no-button deployments by appropriately tagging a particular version in the VCS for release.