All of their issues are self-inflicted. What benefit is there to their cloud backend except getting around the home NAT? If you want to build your IoT product privacy-friendly, your cloud offering can be reduced to a STUN/rendezvous server and a proxy server as fallback [1]. Ship your devices with individual tokens to rate limit the proxy, have the STUN/rendezvous/proxy server address configurable and publish their source code for users to not be dependent on your continuous operation.

You can even go so far and have a public sub domain for each devices ( serialnumber.manufacturer.com ) which you only operate as a dumb proxy so that even the TLS certificates are negotiated end-to-end between the IoT device and Let's Encrypt. (The devices connect to your backend via Wireguard and you rate limit with their device individual key, whose public key you read out during the end-of-line production step.)

Hell, with today's browser heavy applications you can even run the whole slicer in the browser. Let the app be distributed via CDN so the code does not need to go through the proxy.

[1] In the case of non-battery operated and always or mostly on devices, like 3d printers at least.

I dont understand what the issue is. Theres not really any benefit in having cloud enabled if local is working fine. I have my bambu printer set to local only, and dont miss the cloud offer one bit.

Sure, but it's their right to enact that restriction on their software. There are more open alternatives like Prusa , Elgoo, or Creality if people prefer a more open/freedom approach. On the other hand, Bambu has a reputation for having most of the best products in the space.

Of course, many prefer to break their license agreement because They Really Want It, in effect daring Bambu to get aggressive with license enforcement. They probably won't...