Warning, very subjective.
Just to start off on the right foot... 
I really like Ubercart. At least the core elements. The Uber-API is for the most part extremely well done and it has only gotten better by time.
My background.
I've been involved in the development of (what I believe to be) some of the largest Drupal and Drupal + UberCart sites to this date. At our company we have created and currently maintane several sites in the million+ node range. The technology we use includes Apache2/Varnish, integration with search engines like Solr and Sphinx, Pressflow Drupal-release, integrations with backoffice systems like M3, Movex, Visma, IBX/Basware, and product integrations with Nielsen Bookdata, Bokrondellen, Boknett, Campus Ebooks thus combining millions of physical and electronic products. As for experience with the Drupal source, I've been both left and right, up and down the code and feel I have a pretty well understanding of all the code for Drupal version 4, 5 and 6.
I really like Drupal and it's system based on hooks. It rocks! Same thing with UberCart. It rocks!
Then to my surprise, things like Workflow-ng and Conditional actions (CA) appeared. At first I didn't know what to think about it. It might be a nice addition to Drupal's functionality for doing simple tasks. But to my surprise w-ng and CA have been used for mission critical tasks like decrement stock and changing order status. Just to top it off, those actions are actually activated as default!
What I don't like
1. Invoking:
module_invoke_all('uc_checkout_complete', $order, $account);
ca_pull_trigger('uc_checkout_complete', $order, $account);
This just does not seem right? We have this nice hook-based system here - look at the first line. Why can't we continue using it? With this setup, a search for "_uc_checkout_complete" will not return every possible angle for execution of this code, because there might be 0 to infinite conditional actions here... I've banned the use of CA/w-ng at our company because of this.
2. Name of the tasks and figuring out what they actually do
"Update order status upon checkout completion with full payment"
"Update order status on full payment"
These two "came" activated as default on our latest Drupal 6 + UC site. What do they do? Sounds like they would be in conflict of each other. They also initiate some serious mission critical tasks. We use the order status for payment control, credit/capitalize electronic payments, set electronic products as inactive, export data to 3. party systems.
3. Tasks being severely limited
"Decrement stock upon order submission"
What if we cancel the order? Shouldn't stock be increased?
4. Descreasing the functionality of the ordinary Drupal hooks
mail id : uc_order_action-mail to : admin@shop.no from : support@store.no subject : New order registered at Store
mail id : uc_order_action-mail to : customer@shopping.no from : support@store.no subject : Your order at Store
This is the output of data sent to hook_mail_alter in Drupal 6 for the two e-mails sent when an order is placed. One email to customer and one to store admin.
The only way to identify the proper mail is to check for mail id equals "uc_order_action-mail" AND then to a check on the subject. The value of subject is a factor of the chosen language... If I had my way, mail id would be the only way to identify e-mails sent from the system and I believe it's the way it was intended to be.
Each type of email sent, should have it's own ID!
5. Overhead in execution and development
Look at point 3. We have built our own module, doing decrement, increment, and other tasks, all based on hook_order and hook_uc_checkout_complete. It's really just a few lines of code - it's a bit more, because we handle product bundles/electronic products/deactivation of products from search which are out of stock - but the core functionality is pretty easy. The functionality can be disabled/enabled by going to admin/store/settings/stock.
We started off thinking we would create CAs for this, but it turned out to be quite a large undertaking and would require a lot more work to accomplished the same thing, while being even more prone to errors than just using the standard hooks.
I just can't see any positive sides for using CA instead of just using the standard hooks and module-system.
You would be a totally crazy to activate any of the two CAs in example #3, without actually going over the PHP-code behind each action. As I see it, this negates the whole "CA is for non-programmers"-reasoning. Anyone with the need to look at the code and understand it, would be much better served having to just learn the ordinary hook/module system, not having to work out the quirks of CA too.
Where I have written "CA", just think workflow-ng, conditional actions, rules...
This probably comes off like huge rant. Maybe someone here can explain to me the positive sides of a semi-programable-ambiguous-"conditionally executed actions based on occurring events"-system? =/
