I downloaded avrdude 5.11 and 5.11.1 source, and applied the [equivalent] patch to arduino.c in both versions and successfully tested them under Debian Linux (2.6.32-5-686 kernel), with Arduino 1.0 (compiled from source, modified installation to use compiled avrdude in lieu of the one that ships with the Arduino environment, verified by using 'verbose' upload option).  Subsequent regression test was unable to reproduce the original problem in Debian Linux i386, as with FreeBSD-7.2-STABLE.  However, neither of the avrdude versions had any problems running with the recommended change applied.

I do not currently have the ability to test avrdude properly with FreeBSD 9 but I do not see any reason why it would not work with the changes applied.

I did some 'scope' work on the device and it appears you are correct, i.e. RTS+DTR set to 1 brings the digital line low rather than high.  As it turns out adding the extra '1' causes the Uno to reset where it had not been doing so before, but this may have been an anomoly.  What works even better is increasing the time delay between setting RTS+DTR to zero and setting RTS+DTR to 1 in the avrdude code.  I have added a patch that changes the delay time from 50msec to 250msec, and I have made repeated tests to make sure that the results are consistent.  The purpose of the increased time delay is based on what I discovered when I scoped the reset signal.  I was literally getting 2 signals, one in which the reset level was usually above 1V during the pulse, and a second one where the level dropped below 1V and (usually) caused a reset.  After applying the new patch, the Arduino Uno resets happen consistently and I don't get any more programming errors.

in order to program the Arduino Uno there is code in arduino.c that sets the RTS+DTR lines to low, then high again.  Unfortunately in FreeBSD 8.2-STABLE the RTS and/or DTR lines may not be in a 'high' state prior to this.  To prevent this from becoming a problem, I recommend a simple patch that sets the RTS+DTR to a high state prior to going to low again and back to a high state.  The high to low transition is necessary to perform the reset properly, and the patch guarantees it will happen at the right time.  It should be pointed out that in earlier versions of FreeBSD (such as 7.2-STABLE), the libusb port was being used and this issue did not show up.  So it appears that the code was relying on both the RTS and DTR lines to be set high during a device open.  Since this is (apparently) no longer the case, or is not RELIABLY the case, adding the extra 2 lines of code ensures that the lines WILL be in a 'high' state before doing a reset.

related information (and patch) in FreeBSD bug report:
http://www.freebsd.org/cgi/query-pr.cgi?pr=163749