Assuming you're limited to the two version control systems (VCSs) you mentioned, Subversion (SVN) will be clearer, easier and better supported in almost every respect, until you get to the point where you must support multiple branches.
When you need to merge code (e.g. bug fixes) into multiple versions, support parallel development of any significantly sized features or by a slightly larger team of developers then ClearCase, and more specifically the ability to develop in branches and merge them together easily, will become worth all the extra pain and complication - especially if ClearCase is already being managed for you.
Experience
I've used ClearCase with between one person (me) and more than 400 people, It has many day-to-day annoyances, usability issues and faults but it consistently allows us to get work done together. At all times the ClearCase installation had dedicated full time administrators.
I've used Subversion by myself and with one other person, and it works great day-to-day (with no administrators except for me) but it very occasionally but consistently becomes a significant source of frustration due to the fact it can't handle any significant branch and merge situations.
Why is SVN poor at supporting parallel development and branching?
SVN fails in the support of parallel lines of development because it has very weak automated support for merging branches together. In contrast all the other VCSs that I write about here have good support for merging branches together; for the common cases it is a zero effort operation.
Branching is the way that version control systems model concurrency in human life (e.g. two developers work on two different issues in parallel, or one developer who has multiple issues open at the same time). But branching is useless if you can't easily combine everyone's work into a coherent whole!
Branching can happen explicitly (in that they are named and understood by the VCS) or implicitly (as a normal copy of the files or a checkout). SVN supports both, but in SVN branching is usually done in a implicit limited fashion. Each check out is a branch but all branches are forced to be synchronised on every commit/update. This happens because SVN does not support easy merging of explicit branches and therefore explicit branches are rarely created.
As you're forced to synchronise with each other at every commit this decreases the potential parallelism within the team. It also leads to some less than ideal development practices as you cannot effectively use the version control system for your own day-to-day development needs. It ends up being too hard to try out different ideas in your own personal branches and you cannot make multiple commits while refining a feature. You are also more likely to commit too early and end up breaking everyone else's work until you fix the problem in your last commit.
The other major issue is that, since merging explicit branches is not well supported, SVN does a poor job of helping you move code changes between people and between branches. Imagine trying to fix a bug in both the release branch and the development branch; alternatively imagine two developers are working on a related feature and they both need to have each others changes, but only at controlled points. Using SVN you can accomplish these tasks but the VCS does very little to assist you and you must be prepared to manually prepare and maintain patches or ship around files.
In the other VCSs you can ask the VCS to merge a branch containing a bug fix or a feature into various other branches. At the end of the day all these branches (which themselves contain the contents of other branches) can then be merged back into the main branch. More often than not most of this will be handled automatically and correctly by the VCS, whereas with SVN having this kind of automatic flexibility and parallelism is almost unimaginable.
Large teams do get work done without strong support for automated merging but this places a greater burden on both the individuals and on team organisation, communication and process.
On the flip side, the downside of easy branching and merging is that you must be organised and rigorous about merging changes together at regular intervals as it doesn't happen automatically any more.
Other Options
Now if we take a step back and consider other systems, assuming your repository is mostly text based and relatively small (less than a few hundred MBs), I would suggest you seriously consider using BZR. BZR is at least as easy to use as SVN, especially if you already know SVN. It is also at least as powerful as ClearCase in all important respects from a developer's perspective; it supports multiple streams (branches) of development and has good support for merging them back together. At the same time it can support a centralised style of development as necessary.
Although I have no experience with it I should also mention that you can use the BZR tool to access an SVN server with bzr-svn and this may give you much of the benefits and merge capabilities of BZR while still having the advantage of hosting your code on the widely understood SVN platform.
While I just suggested BZR, in the world of open source distributed version control systems (DVCSs) many people appear to be going with GIT. I didn't suggest this though since it forces a much steeper learning curve on users coming from an SVN background and I think many teams in the wild would prefer the better Windows support and ease of use of BZR above the scalability and speed benefits of GIT.
If you choose to go with a DVCS like BZR or GIT you probably don't need to get too hung up on exactly which DVCS you start using. The widely used systems all support exporting and importing between each other and can all at least import from SVN.