I can provide a more specific answer from the CumulusCI perspective. First off, the webinar you linked to is quite old. Here's some better reference materials:
Dreamforce 14 Session Videos:
As for a working example, we actively use CumulusCI for a number of open source managed package projects so you can easily see it all in action:
One important point is that CumulusCI is built pretty exclusively for development of Managed Packages rather than for maintaining single org customizations. That said, probably 80-90% of it would be reusable for a single org scenario. I just haven't actually had the use case to build that yet and thus can't speak to if it's a good fit.
If you're doing Managed Package development, the key thing to keep in mind is that your repository should contain the metadata that's going into your package. The only thing you can put into a Managed Package is metadata. Metadata can be easily worked with as files. So the developer's workflow for package development is retrieving and deploying files to/from a Salesforce org and the version control repository.
All merging of code is done via Github Pull Requests which are also used to track code review. CumulusCI also includes a script which can automate the push of new commits on the master branch (i.e. after a Pull Request is merged) into all open feature branches so the feature branches track as close to master as possible. This has been really helpful in our productivity as it reduces test/build failures and merge conflicts.
package.xml and retrieve/deploy
As for the package.xml question, developers are deploying and retrieving the entire set of package metadata when they use the build scripts. Retrieves use the packageNames attribute to only retrieve the metadata in the package. This type of retrieve doesn't require a package.xml manifest, just a package name. Deploys use
<fullName>Your Package Name Here</fullName> in the package.xml to specify that the deployed metadata should all be automatically added to the package. This makes a round trip container for your metadata to get into and out of the org. If a developer adds new metadata, they can use the
ant updatePackageXml target to rebuild the package.xml based on the metadata in the src directory.
Shameless Community Pitch
CumulusCI was built to prevent the reinventing the wheel you alluded to at the start of your question. It's open source and the build scripts are architected in a way to encourage contributions back to the main repo, allow users to easily update the build scripts (git pull), and has built in hooks providing projects the flexibility to override core functionality for project specific needs.
I will confess is that the documentation for it is definitely lacking. It's not necessarily my strong point and I'd love to work with someone in the community who would be interesting in writing documentation to make it easier for others to use CumulusCI.