BF is still a great tool for continuous integration.  JBE is simpler than BF, and BF addresses the needs of users who need a more complex build solution.  I don't know what plans there are for future releases of BF, but BF is definitely a mature product for users looking for a Rational build solution

I wouldn't exactly call BF mature.  the adaptors are clumsy.  They remind me of the old CruiseControl/CC.NET way of working, playing in XML.  Plus the adaptor templates are pretty limited.  Why isn't there a continuous integration one?  Look at what Hudson/Jenkins did, it's way easier, and I can quickly get it to watch a branch on a set of VOBs, polling every x minutes, and if a branch changed, to fire the build off.  I don't need to know the syntax of a cleartool lshistory to have it check since the last time to see if something was checked in, I just enable it.

Really, I want it to do continuous builds, and I have to instruct BF how to do that?  Why isn't it out-of-the-box ready to easily integrate with clearcase or RTC, where you can just graphically configure a plugin? The CI portion should be just there when you configure a project to use clearcase (one for base, one for UCM), with quick enable checkbox to poll for a branch/stream, and a textbox to specify the branch to poll.

Also, I don't really like the logging (the jobs), I sometimes have to refresh to see the logs, while hudson/jenkins, it seems to work much more reliably, like a tail -f would work.

It would also be nice for environments to load an external file that contains the environment variables (like for visualstudio if you want to run devenv, where you can set a VS2010_env that would load C:\Program Files (x86)\Microsoft Visual Studio 10.0\common7\tools\vsvars32.bat, but for VS2005 builds, you could have it load the Visual Studio 8.0 version of the batch file as defined in environment.  That way you don't have to do a call %VSCOMNTOOLS%\vsvars32.bat in your command, and just get down to chdir then devenv.

And have a check as well in the environment, so it can check to see if, oh, java -version is pointing to the correct version of java post-login, but pre-build,

I would disagree. I've done some really cool stuff within hudson, and I'm not sure what the unnecessarily complex adaptors buys me that Hudson can't do (assuming no plugin recompile).  Generally, in a CI tool integrating with clearcase, I generally would want it to:
1) easily integrate with CC (where's cleartool, do I create a view or use an existing one),
2) easily identify which VOBs to monitor for this project
3) which branch(es) to monitor for changes
4) how often to check for changes
5) how easy is it to schedule regular builds
6) How easy is it to specify the build label syntax
7) How easy is it to use the values (like build label, vobs I'm checking, etc.) inside the command portion
8) How easy is it to set the build view's config spec (maybe it just builds off the label, maybe it's a new label pushed on top of existing labels, maybe it's just a branch/LATEST config spec or some timestamp config spec.

Everything else is generally handled by the command portion.
If necessary, mklbtype in the appropriate VOBs
check if VOBs are mounted
attach labels
lock labels
gathering environment variables
Then run the setview -exec for dynamic views for cd'ing, setting env var's, then building
then monitor build results, then do something with it:
- failure: email, page, etc., maybe add an attribute to a label indicating it's a bad label, record it in some text file, whatever, then exit.
- success, email, text, etc., kick off unit tests, kick off deploy jobs and regression tests, etc.

I just think BF got stuck in 2008 (4 years ago now), and if they are serious about this tool, they need to update it and make it easier to use, or else people will go towards the cheaper easier tools.  Playing in XML is just laziness, kinda like writing java code in vi instead of eclipse, c# developers coding in notepad instead of VisualStudio.  Wading through the numerous XML tags, comments, etc. trying to find the exact tag to modify, trying to not delete the wrong thing (mismatched ", forgetting to close a tag, deleting a line I shouldn't, bad xml syntax, etc.) especialy in that tiny little textarea (yeah, I could probably find it and modify it with my favorite text editor, but still, isn't that what BF should do for you?

Using something that helps you build an xml file is much nicer.  I don't care if you want to keep that an option, but there should also be a real tool to help you generate the xml easily for stock situations, and I don't think what I'm describing above is an exception.

From a Base CC perspective,
What VOBs
what branches
how often to check to see if BF should do something (every 10 minutes?)
do something anyway if time=x?
sleep x minutes if 'do something' is true (to give time for checkins to complete)
what view (create it too?) do do something in?
what config spec (which could be altered in the command portion)