[Sativo]

Sure, I understand. It may not be for everyone.

As for your points/questions, here's the idea:

You mentioned that your accounting system reconciles when an order is imported, so long as the variant SKUs are in the order. And you're right, from that perspective, there isn't a problem. But unless I'm mistaken, your accounting system probably represents each variant SKU as a separate item -- which rightfully so, more closely resembles your real world inventory situation.

So why do it any different at the cart level? It just introduces new conceptual models for users of systems to learn. If you hire on more employees that go between these systems, you can reduce risk if you streamline the way users view and interact with inventory from one system to another.

So that's the argument for the back-end.

Perhaps more compelling is the argument for the front-end:

You mentioned changing prices. Now, pricing/costing (for profit analysis) is really different than discounting (sales) or promotions (buy 1 get 1 free, etc.). Your pricing really should be handled in your accounting system anyway, since there you have the budget and financial reporting needed to do profit analysis.

But discounts and promotions are really just marketing/merchandising abstractions that are layered on top of product prices. So given all the new and fun tools that are always being innovated to help promote and discount products (ex: X-Cart's Special Offers, AlterCart's Buy Together module, and so on...), the current variant paradigm is limiting.

Example: Say you have blue, white, and red socks, but only the read ones aren't moving. You may want to put them in a discount bin. But, if a user views them, you might still want them to have the choice of selecting another color option.

There's really no end to the possibilities because the variant product uses the same product object in the cart framework as any other product.