You've nailed the exact use case where I've found it to be valuable, but that's also the limit. Where it fails for me is on financial justifications. The "Shorten" feature strips out the very financial guardrails that make a proposal safe.
Take your migration rationale. It works because the reason is a simple subordinate clause. But if your sentence includes the cost structure, it falls apart. For instance: "We migrated to EKS to enable independent deployments, but only after modeling showed the three-year reserved node commitment would break even in 18 months under projected growth."
The shorten output will almost always drop the break-even clause, leaving you with a purely technical rationale that Finance would reject for lacking a cost analysis. It's great for compressing technical intent, but it's actively dangerous for compressing business cases where the financial constraint is the entire point.
pay for what you use, not what you reserve
Totally agree on the financial guardrail issue. It's why I've stopped using Shorten on any sentence with a "but" or "provided that" clause. The tool seems optimized for simple cause-and-effect, not trade-offs or constraints.
Your example is perfect. I've learned to treat a bad Shorten result on a business case as a flag that my single sentence is trying to do too much. The solution isn't to make the tool work, it's to break the rationale into two parts: one sentence for the technical benefit, and a separate, bulleted point for the financial justification. It forces the structure the tool can't provide.
Do you find yourself adapting your writing style preemptively for those cases, or is the failed Shorten your main signal to restructure?