But then it's not really continuous integration anymore is it? Having a CI server and practicing continuous integration are not the same thing.
From what I can tell, this just makes it easy to run tests in branches. My team uses something similar that kicks off a build whenever someone comments "build it" in a GitHub pull request, and posts the results to the pull request discussion.
Also, feature branch development is just how we're using it. The code monitors git for any new branches and automatically clones jobs for new branches. This would support a more traditional master branch with release branches created periodically. Those release branches would automatically get Jenkins jobs created for them instead of someone manually having to do it.
Unit tests are quick, but the full set of unit/integration/functional tests? Plus ensuring that artifacts like .war files can be successfully created, and that it runs fine on the target system rather than just on your dev laptop (which for most devs is not the same platform as they deploy to).
What if you want to show off your work-in-progress by having a job auto-deploy it to a test server so that your customers or QA can play with it before you're ready to merge to master? Sometimes a day is too long to wait to show something off. Commit and publish as a branch and you can keep working while someone else looks at it.
We have another dev code review every pull request to master to ensure code quality as well as spreading knowledge of what's happening across the team. The overhead is surprisingly low. Branches literally take about 15 seconds to make, and pull requests are no more than a minute or two unless you really go into testing instructions.