At work we used to use Visual SourceSafe for many years before switching to Perforce last year. It is definitely pricey, and we also have Ant build scripts running under a "build" user which counts as one licensed user which kinda burns. The company paid for a 2-day training seminar so the devs here got up to speed pretty quickly, but there are still questions now and then over how to do foo, etc (I am part of a small group here that supports the other users on Perforce issues - mostly because of the way Visual Studio works, not really Perforce itself).
In terms of using Perforce, I think the biggest difference is in the way Perforce conceptualizes the whole task of keeping track of your changes. For instance, subversion keeps a directory named .svn to hold metadata about the files; with p4, the p4 server itself keeps a list of which files you have. This seems to be the biggest source of issues - someone tells the p4 server to get the latest files for a project, but then manually deletes something. When he/she asks the p4 server for the latest again, the p4 server thinks he/she already has it, so it doesn't get updated. Once people "get" this, it becomes much easier to work with. You just have to tell the server to "remove from workspace" and then get it again.
We have a mix of MS Visual Studio users as well as Eclipse and IntelliJ, and the p4 plugin support for all these work quite well. The daily routine of checking in/out and getting-latest is no different. We are mostly using the basic functionalities and even then it seems to be an improvement over Visual SafeSafe (then again, from the rants I see sometimes on the net over it, probably anything is an improvement over Visual SourceSafe). Just having multiple open changelists at the same time gives some of us a lot of flexibility with how we work. It seems Perforce plugin setups prefer silent checkouts which a lot of users noticed right away, but I like it a lot and I think overall it's an improvement for productivity. The IDEs will highlight file names in a different color, so you can see if somethings been modified - and the p4 changelists always show what you have checked out anyway.
Merging changes when multiple users have checked in changes to a file is pretty easy. The diff tools aren't super-spectacular but we can compare conflicts by line pretty well and just click through the ones we want. I should note that the gui tools are excellent. Most devs here do not use the p4v client, but some do and I for one use it all the time. Did I mention the gui tool is excellent? You can look through all submitted changelists, look at file history, drag and drop one revision onto any other revision and get an instant diff, look at a revision graph which shows you branching history, look at a "time-lapse" view of a file's revisions (very neat feature - drag a slider back and forth across the top and watch the file contents update with each revision).
We have only done a few codeline branches so we're not very experienced with it yet. So far, it has been very easy, and merging changes is also pretty easy. As part of the training course, everyone got a copy of "Practical Perforce", written by Perforce's VP of technology or some such. There's quite a lot of content in there about different methodologies for handling codelines and branching. I think when we used SourceSafe, we were so limited in what it could do that we could only think a certain way - Perforce is so much more flexible that suddenly it's actually possible to have different philosophies on when/how/why codelines should be set up, etc. So in this regard we are still trying out a lot of things with regards to branching and integrating (merging).
P.S. A two-user setup doesn't require a license and only limits you to 5 workspaces. You can evaluate it without a time limit. They also offer free (but unsupported) licensing for open source projects.