Its purpose is to lay out a source tree by mapping arbitrary checkouts to subdirectories.  The .gclient file is the master control for the tree, and the individual checkouts can also contain DEPS files that tell gclient to check out additional necessary components.

A checkout URL can (and usually does) contain a revision number, which means you're going to check out and build from that specific revision of the module in question.  The advantage is that you can build from a known working revision, even if it comes from a completely different SCM repository.  The drawback is you have to manage the revision number(s) by hand.

The .gclient file lets you override where a subdirectory gets its source by filling in the "custom_deps" dictionary with your own mapping.  So, as one example, the current src/chrome/DEPS file specifies that the "src/v8" tree gets checked out from revision 101:

So 101 is the last V8 revision that's been built into a known good development version (i.e. made its way through the tests) and "approved" by getting checked in to the chrome/DEPS file.  If you wanted to see how (or whether) Chromium builds and works with the latest and greatest from the V8 team, you could update your .gclient file:

And then it would sync from the tip of the V8 trunk.  You could obviously specify a URL to sync from a different specific revision from the one in the chrome/DEPS file, or even to sync from a completely separate branch containing some cool new functionality, etc.

Overall, gclient provides a pretty good compromise way to use code from arbitrary SCM repositories (thereby avoiding having to check in a separate copy, keep it up-to-date with by-hand checkins, etc.), while still controlling what we're building (so we're not subject to arbitrary breakage from someone else's bleeding-edge checkins).