Input voltage range is -0.5 to 5.25V (Saleae) or ?? to 5.5V (USBee). The trigger is fixed at 2V (high) (Saleae) or 1.4V (high) (USBee).
The input ranges won't be happy with, for example, the RS-232 side of a serial line without clamping the, e.g., +/- 10V swing to be within those limits. Of course, that clamping has to be isolated from other serial devices that may not be okay with a 0-5V "RS-232'ish" signal. One could probe the logic-level side of the line driver if it's accessible or else rig up a MAX232A clone on a breadboard to shift 232 levels back to logic levels.
The fixed trigger voltage simplifies the design and lowers the cost but may impose limits on flexibility. Some signals (e.g., CAN) may not cross the trigger thresholds without, again, some external "help."
I haven't used either of these but from the blurbs on the referenced web pages that note that the acquisition speed is limited by the USB bus speed and bus loading, it looks like the timestamps are applied on the PC side, not the device side. It communicates over a packetized bus (USB), therefore the timestamps can be affected by other traffic on the USB. If there are, say, a USB serial port and USB JTAG or ISP also on the bus, then accurate time stamping will be ... problematic. Trying to figure out how much jitter there is with an interrupt service routine? Good luck.
USB logic analyzers can have a lot of bang for the buck (and I use mine frequently). They tend to fall into two general classes: deep sample memory or shallow + compressed sample memory. The deep memory devices (typically around 1 Mbit per channel) force a tradeoff between precision and total capture time. Sampling with a 0.1 usec precision can't run for longer than 0.1 seconds. Is that a problem? Could be in some scenarios.
The compressed sampling devices tend to run a few Kbits per channel. Compression does allow for long delays between events at quite high precision. However, they can also be quickly exhausted if one of the channels has a lot of high speed transitions. Getting long and precise captures of neighboring signals would probably require dropping the very active channel, which might not be ideal either. Life sucks ...
So, look at the front end and consider if it is wide enough and flexible enough for your needs. They're probably great devices where their input ranges and your problem domains intersect.
On the sample side, I would run away, fast, from any one that added the timestamps on the PC side of a USB connection. I don't know that these do, so maybe a current user can jump in here. On the question of deep versus compressed memory, I personally go with compressed for the flexibility.