There's one fundamental problem about Continuous Integration (CI) that is perfectly mirrored in your question: CI practices are hard to implement and defend because CI server software is not trivial to setup, nor is it trivial to get your projects up and running through a CI server. With this, it becomes hard to actually see where's the gain in embracing CI at all.
First of all, CI is about insight and quality. Good CI brings you closer to your project, gives you proper feedback on quality metrics, documentation, coding standards compliance, etc. It should provide you with the tools to easily visualize all this, and allow you to at-a-glance recognize and easily associate a set of changes with a specific snapshot of all these project metrics.
It is not just about running unit tests. Not at all! Which brings me to quality. CI embraces errors, it does not avoid them or throw them away. What it does is quite simply provide you with a tool to error out early on, instead of later on. So you don't really commit previously tested code to a CI server. Although you should strive to commit clean and not broken code, you actually use the CI server to automatically run an integration builder automatically through your code and have it assess if everything came out right. If it has, neat! If it hasn't, no problem - good CI practices state that your next priority should just be to fix whatever has become broken. Which, in a good CI server, should be easily pointed out for you.
As a team's size increases, integration of everyone's code naturally becomes harder. It should be the task of a centralized CI server to test all integrated parts and take that burden off the team's members. So you must have everyone commiting early (and as cleanly as possible) and then monitoring builds status (there's usually notifications envolved). And again, if something gets broken because of some developer's commit, it immediatelly becomes his responsability to fix that and get those automated builds back to OK status immediately.
So you see, in my opinion every single project benefits from being Continuously Integrated. The thing is, until now and due to mind-boggling complexity from every single CI server I know of, people really fended off CI practices on smaller/simpler projects. Because, come on, people have better things to do than spending days configuring an ugly, overly-complex, under-delivering, bloated software.
I had this exact same problem, and that's what made me develop Cintient in my free time since about a year ago now. My premise was to make it simple to install, configure and use, and to make it deliver on those quality metrics that every one else pretty much fails or underdelivers. So, after this long answer comes my shameless plug of pointing out the GitHub link for the project (which is free and open-source, natch). It also has some nice screenshots, apparently. :-) https://github.com/matamouros/cintient
Hope I helped you.
(NOTE: Edited after Bryan Oakley's comment, on the fact that I should have taken more time to build a better answer. I also think he was right.)