Paolo-
I hear you! 
At the end of the day, I think we are both asking for the same thing: a reasonably priced, reliable, small/medium sized business phone system with a Cisco label on it.
The UC5xx / CME approach, in my opinion, has been tried and has not been the most successful. I am suggesting that perhaps it is time for a new approach.
My idea is a scaled down version of software that already exists and works. I envision a UC-SMB solution that could be delivered as a virtual appliance or a physical appliance. The physical appliance should be priced similarly to the current UC5xx models, while the virtual appliances coud offer a modest discount. The BE3000 is server based, sold as a physical appliance, and it is a very nice product indeed. (it also shows how the more complex UCM can be simplified for smaller markets!)
I know you mentioned that you do not want a "server" based product, but my contention is "why does it matter?" - as long as it works, is reliable, and affordable. CUE, for instance, has been "server based" since its inception. It runs on a custom build of linux on its own processor, memory, and disk. In CME, it is installed as a daughter card in a router - in the UC5xx, it is still separate from the main unit (though it sits in the same physical box).
Heck, you could even leverage an SRE module to load up my proposed UC-SMB solution and still maintain the ability to install it on (or within, anyway) a router.
The UC-SMB solution that I envision would eliminate the need for two teams within Cisco, with two different feature matrices, two different support structures, two different approved device lists, and so on. The virtual appliance would (quite obviously) support SIP trunks only. The physical appliance (perhaps based on a C series UCS server) could be sold just like the current UC5xx with an embedded T1/E1 card (or ISDN) as well as some FXO/FXS ports. Best of both worlds. Of course the proposed UC-SMB would need to include some features that CME has had for years but yet UCM still lacks, things like BACD and simple paging. A UC-SMB solution also provides a clean upgrade path to UCM-BE or UCM whereas the current UC5xx/CME solution does not.
Paolo, you do make a great point about CLI. Yes, I love the CLI in CME but that love stems from the fact that it allows us to do things that we simply cannot do with CCA. That said, the troubleshooting capabilities within UCM are fairly extensive (RTMT) and there is no need for a CLI because everything is (and always has been) within the GUI. (The lone exception here is CUBE, but that is beyond the scope of this discussion!)
Perhaps asking for a unified code base between CME and UCM is too much? I'm not sure. Honestly, if Cisco could produce a working and reliable UC5xx with relevant features for the current market place (mobile clients, working presence, working operator console??) and a tool that can configure 100% of the functionality without the need for CLI (and better, without breaking things that are done via CLI), then we might be on to something. As it stands, Cisco seems to be struggling with unifying the code bases of CME and UC5xx - and that is disheartening.
Remember, I am a HUGE Cisco fan. My experience with Cisco goes back to the 100x/250x routers. I just want an SMB PBX product that can be deployed without risking my business reputation. Right now, I'm afraid, Cisco does not offer one.
I do hope they get it right soon, though. For all of our sakes.
Rick
PS - yes, the UCC/SCC software and related Operator Console have made HUGE strides, but there are still a number of lingering bugs that make the presence unreliable. If an operator transfers a call to someone she thinks is off the line, and that call ends up in VM because the user is busy instead of being parked, bad things can happen. We've had a client report lost sales as a result. Not good. I've never had this issue with the equivalent tools (presence, CUBAC/CUEAC).