(Scroll to the bottom to get my overall opinion, but as a summary: it could work.)
Bugzilla is one of the most widely used BTS'. Several large projects/organizations are using it, including the Mozilla project, the Freedesktop project (i.e. X.org + related tools), the Linux kernel, Eclipse... it goes on. I would say it's the most popular in the free software world.
There seems to be a lot of manpower in the bugzilla community. Releases appear well-supported (3.0 came out in May 2007 and that branch just saw a release a few months ago), and there have been numerous recent releases, suggesting it is under active development. There are mailing lists, newsgroups, and an IRC channel to get help should we have issues. There are also a lot of for-pay consultants available should that be desired.
Searching was fast and found appropriate results on most bugzilla's I tried. Freedesktop.org's bugzilla was, notably, rather slow. The 'advanced' interface is a bit overwhelming.
Bugzilla has a 'reporting' feature which can generate all sorts of charts and the like based on a ton of parameters. I've found it too confusing and overwhelming with all of its options, and never obtained useful results out of it. YMMV.
Supposedly, bugzilla does not support custom fields. While searching around on this, I found out that this was by design, and I got convinced that custom fields really are a bad idea. Yet I also found this:
http://www.bugzilla.org/docs/tip/en/html/custom-fields.html
that's from (current) bugzilla documentation, which explains a mechanism by which an administrator can have custom fields which get automatically entered as comments on a bug report.
Then I noticed on their 'Features' page that they list "Custom Fields" as a feature. I don't know what to make of all this. My guess is that they initially felt it was a bad idea, but semi-recently caved to public demand.
I haven't setup a bugzilla myself. It looks like your typical LAMP (well, Postgres works too) setup, which I haven't done manually in quite some time. I would say that process is difficult for someone who has never setup apache or a database. My current Linux distribution includes a bugzilla package, so maybe this is a moot issue.
Email: Bugzilla supports managing / commenting / interacting with bugs via email (including email notification when a bug changes). I have found this immensely useful, as browsing to a bug site and logging in just to comment on a bug (or even see if a request for more info is available) is immensely annoying.
Privacy: Bugzilla allows one to mark certain bugs or components thereof as 'private', only visible to a select group. I imagine our LLNL colleagues would find that feature useful.
Programmable interface: It uses XML-RPC, which seems to be the standard for web stuff. I don't think I'd ever write my own tool for it, but bugzilla is popular enough that it's likely someone has implemented useful things already. A quick google search finds this:
http://www.mombu.com/programming/python/t-pybugz-python-command-line-interface-to-bugzilla-1096479.html
Subcriptions: One can 'subscribe' to a particular search as an Atom feed, or integrate bug planning with iCal.
Reports: The aforementioned charts that I've never been able to get useful information out of.
Time: One can attach estimates of how long a bug will take to fix, deadlines, etc.
I think bugzilla could work for us. It seems like it supports everything we'd need, and there's a lot of support behind it so we could probably figure out how to configure it to our likings.
I worry about the support costs associated with it. The community rabidly jumps on security fixes (which is great) but the project is updated frequently && one might be concerned about running out of date versions of the software. It seems like upgrades for minor releases are pretty quick and painless, but I still wouldn't want to be the one 'responsible' for making sure our bugzilla is at least security-clean.
This would be a moot issue if we could get an organization to run it for us.