Your business analysts are currently doing the product design by proxy. Use cases are supposed to be a way for the business side to identify and communicate the product's business requirements to the design side, who then does the actual product design to meet those requirements. Use cases are not supposed to be a point-by-point description of the product workflow: the business side should certainly not be designing wireframes(!) -- that level of detail is clearly outside their (presumed) area of expertise.
So, you're right, they're wrong. Knowing that doesn't actually help solve the problem, of course.
This is a structural / territorial problem within your organization. Currently, they're the ones defining the product, and you're the pixel-pushers whose job is to make it look pretty.
This might be the result of unusually weak leadership on the UX side, unusually strong leadership on the business side, or both. It may be that your UX team really is mostly a graphic design team, and lacks the skill or or experience to take control of the full design process; or it may be that the business side just doesn't understand or respect the value of product design skills. Probably it's some combination of all of the above.
There's no easy solution to this, unfortunately: being correct about the fact that they're overstepping their bounds -- which you are -- won't actually get them to stop overstepping their bounds.
Pushing back with phrases like "you're squashing our creativity!" is highly unlikely to be successful, because it feeds directly back into that narrative of designer == pixel-pusher (to the average non-designer, "creative" is code for "unserious" or "frivolous"). You're also unlikely to get very far by telling business analysts that your analysis skills are important -- to their ears, that'll sound like you're trying to step into their territory.
Instead you need to find a way to demonstrate your skills, in a provable, measurable way, so they can see that a workflow designed by someone whose expertise is designing workflows is superior to a workflow designed by someone whose expertise is identifying business requirements. An A/B test comparing a strict-by-the-numbers workflow designed by the business side to a UX-designed workflow might sound tempting, and might even work -- but it's a highly confrontational solution, which may cause them to dig their heels in even further regardless of the results. The real solution is likely to be a more incremental matter of closed-door discussions, reaching out to allies in upper management, and building leadership and authority within the UX team.
TL;DR: someone on your team needs to get a lot better at office politics, fast.