@giwook: The description says "Don't worry about uppercase vowels."
So the test cases cannot contain uppercase vowels.

Still, I would definitely not consider this solution "Best Practices" or "Clever" as it in principle is removing more than the lowercase vowels...

This code does fail on AWUBWUBWUBWUBB incorrectly putting 2 spaces between A and B: "A B". So it is cheating the test cases...

Probably my newer version is easier to read...
But the idea still is the same.

Indeed, I would prefer the simplified condition to the one in this case. It will be slightly more efficient code, it will be shorter code, etc.

Of course that depends on the number of "special operations" you need to perform. Since it's fine for the current test cases, why bother with writing it out as a while loop?

If there would be a test case which does give this problem, rewriting it to a non-recursive form is the first thing one would do...

Indeed it was a lot of fun to do . :)

By the way, it is possible as a one-liner (see my solution), although admittedly, it is quite a long line. I could make it a bit shorter, but it will be less clear what I'm doing.
And for efficiency, it would actually be better to split my solution up into two lines.

It's an incorrect solution.
It matches #123 while the description clearly forbids it.

You can argue that IVXX=14 or IVXX=16. It is 20 (XX) minus 5 (V) minus 1 (I), or it is 20 (XX) minus 4 (IV). That's the reason why we avoid using confusing numerals like that.
Arguably VIXX would be valid, but this code also won't like it. (This code returns 24, while we mean 20-6, or 20-1-5). But notice that the notation is rubbish anyway: XIV=14 or XVI=16, and both are shorter.

Actually, the definition of Roman numerals used in this problem only allows a single I before V or X, a single X before L or C, and a single C before D or M. No other "subtraction" is allowed. So all these weird cases discussed above cannot occur.
As the problem description states: "Modern Roman numerals are written by expressing each decimal digit of the number to be encoded separately, starting with the leftmost digit and skipping any 0s."

In other words: all these cases are handled properly by the code. And the code even extends on this, by supporting IM (as 999), VM (as 995), IIIIIIIIIIIIIIII (16), etc., which would also be non-ambiguous.