The wonderful thing about mercurial is there is no required way of doing things, you can make your workflow follow what's convenient for you.
I think a minimum system is probably a remote repository and a developer repository cloned from it. But how many deployments you have, how many developers you have, what the lines of responsibilies are and how best you can factor these into your workflow might be very different for different teams and/or projects, even within the same department, let alone company.
For instance, using the example from the hginit that VonC posted, if Bob found a bug in code that Rose maintained, he could hgserve his own repo, she could pull in his changes, update to his tip, track down the problem, and push her fix directly back into Bobs repo (without it going through the central server) before updating back to her own work branch. When Bob was happy with their work (he's confirmed that his integration tests run Ok) he could push it up to the central repository, where Joel could see that it was complete.
If I understand it correctly, this is actually easier than with git where Bob and Rose would be expected to collaborate through a shared bare repository. I suspect that Bob would have to clone his own repository, let Rose pull from and push back to that repository, and he would then have to pull her changes in, rather just updating to a newer changeset in his own repo.
Later, Joel decides that this ad hoc sharing isn't appropriate and that all sharing should go through the central repository, but he doesn't want the head of the central repository to ever be in a state where it doesn't pass integration tests.
To solve this, Bob could set up a staging repository. Any repository pushed to the staging area would have the integration tests run on it by the build/continuous integration server and if the tests succeed, the changeset is pushed up to the central repository. If not, the changeset would be held back until tests do succeed. If only the integration server is allowed to push to the central repository, Joel gets what he wants - Bob and Rose can collaborate by pushing and pulling through the staging area, but the central repository would always have a clean, tested build.
So, in summary, The world is your oyster really.
The scenarios above are just two of a wide variety of different problems you might want to solve through your workflow. The best thing to do is to ask if you have a specific workflow problem that you want to solve, then people can offer suggestions. Until then, it's probably worthwhile just keeping it simple.