One hard thing about trunk based development is when you depend on teams that utilize feature branching and are ok with big bang releases instead of Continuous Delivery.
If every commit goes to main and then production, you can’t “hold off” releasing for 2 weeks or a month.
One of the strategies there is feature toggles; release things that aren’t shown. While the toggle is straightforward, the 2 code paths that could be entirely new type definitions & UI flows isn’t so. Mapping 2 different types to a single current domain’s one is tricky.
More importantly, you appear like an outsider when avoiding staggered releases.
“We’ll just release database changes, API’s, and UI’s at the same time.”
That would mean you’d be committing changes, but never actually pushing them, and never using your CICD pipeline to test them until 2 weeks/a month later.
This is one of the tradeoffs of trunk based dev.
You have to have 2 code paths & feature toggles. You have to remember to remove them later. You have to write enough tests to validate happy paths + ensure they can peacefully co-exist.
Value? When you release you know your stuff works, Because you’ve tested it for a month. That and you don’t have anxiety as much on release day because you know you’re good, and more able to help debug issues on the boundaries that your code touches.