CW follows TDD (Test-Driven Development), so the spec is practically defined by the tests. If subpar solutions/cheese solutions passed because tests do not catch them, you should go yell at the kata author to fix the tests (by raising at issue), not at users for submitting such solutions ;-)

this Kata description is more akin to what developers may face in the real world

Nope, this is far away from a real world mission. Actually all katas of CW, if they are what you say something that developers may face in the real world, are just a tiny subset of real world job.
A more 'real world' version of this kata may contain

• Multiple key info from one sentence
• Configurable suffixes
• Auto correction, like what search engines do
• NLP
• All lowercase input
• Unicode support
• OCR

How many would you like to add to your solution. And what else can you think of a real world challenge may require?

If we as developers understand what they're trying to achieve

Nah, we can never ever understand what others trying to achieve, because we are using natural language to communicate. Just look at how many people cannot even ask a decent question on StackOverflow or else.
What we can do is just guessing what they want actually, and, if we are going to grant their wish, guide them to express themselves more exaclty.

I'd much rather be working with developers that see the bigger picture and ask questions than those who just blindly follow a specification, knowing it doesn't cover the outcomes that the business or customer want.

You are right, and you are wrong.
Real world prolem are much more complex than just a kata
We'd like to add all fatasic features to our produces.
We'd like to cover formal proof as much as possible to make our system bug-free.
But time is limited, resources are limited.
We are doing workarounds for coner cases one by one
Not to metion that good/bad code does never directly lead to popular/shit products
And again, you can never guess what your customers REALLY want.
Also, if the 'specification' does not cover the outcomes, then how the hell it become a specification? Just a partial of requirement document.
And isnt it your job to make it cover the outcome as much as possible at the very beginning?

If you are seeking workmate on CW, then you are coming to a wrong place
We have Anarchy Golf, Code Golf for playing code golfing
We have IOCCC for obfuscation
We have all OJ sites to test if we are good to solve algorithms problems
We have LeetCode for job preparation
We have Advent Of Code for speed coding competition
......
Every site get their outstanding part, not just aiming a same goal.
And CodeWars, WARS! It's a game, between authors and challengers. Solving puzzles! It's fun. What else are you expecting?

And, after modification, the test still not covering all cases, file another issue if you actually wish to make this kata 'better'.

See Issue entered by FArekkusu and the reply to the resolve the Issue.

Nope, in the real world, there are

• Costumers not expressing their requirements properly
• PM not providing requirement difinations that cover all cases
• Programmer not correctly handling all invalid input by users actions
• ...

Descriptions are not specifications, or why do we need TDD or BDD? Because testing codes are more exact to express what authors want than requirements.
So it is the authors that not being consistent to themselves, not a failing on CW.
Take a look at this and this
You see, even the author not solving the kata according to the desc. Why? Are you still going to solve it according to the desc?
There is a failing on CW culture, which is, making it too easy for users to create katas, thus we keep facing katas with low quality again and again. And when katas like this got approved, there will be meaningless arguments talking about not following the desc over and over again.

In fact, it is the test that does not follow the rules.
For every katas on CW, the authors are responsibke to restrict solutions based on the desc by complete tests.
So if the authors do nothing to ban solutions that 'dont follow the desc', then those solutions complete the job perfectly.
// Such as passing strings to function that multiply, you may want it return null, or throw an error, but if you dont test it, you are free to do anything.