First, capture the error that's occurring by printing the error contained in $@:

Sequence (?r...) not recognized in regex; marked by <-- HERE in m/(?r <-- HERE /

From that we see what perl (the executable) finds to be a problem: (?....) is a trigger mechanism for extended parenthesis patterns. For example, (?:...) represents a non-capturing paren. (?=...) represents a zero-width lookahead assertion. But there is no such thing as (?r...). perl doesn't know how to compile that, and generates a compile-time error. You can verify that fact by moving the regexp in question outside the eval block. The code never gets past the compile stage if you do.

But why is it that the "\(" escaped parens are not staying escaped? Ah, that's the mystery. If you change the RE from m(.....) to m/...../, the problem goes away. Double mystery? Or clue perhaps? At first I dug into perlre but quickly realized that the answer had something to do with the choice of parenthesis as quotish-delimeters, and re-focused the investigation on the Quote and Quote-Like Operators section of perlop.

There we can read the following:

Gory details of parsing quoted constructs

Finding the end
The first pass is finding the end of the quoted construct, whether it be a multicharacter delimeter "\nEOF\n" in the <<EOF construct, a / that terminates a qq// construst, a ] which terminates a qq[] construct, or a > which terminates a fileglob started with <.

When searching for single-character non-pairing delimeters such as /, combinations of \\ and \/ are skipped. However, when searching for single-character paring delimeter like [, combinations of \\, \], and \[ are skipped, and nested [, ] are skipped as well.
.....
Removal of backslashes before delimiters
During the second pass, text between the starting and ending delimiters is copied to a safe location, and the \ is removed from combinations consisting of \ and delimiter--or delimiters, meaning both starting and ending delimiters will should these differ. This removal does not happen for multi-character delimiters. Not that the combination of \\ is left in tact, just as it was.

So what is actually happening is that when using m(...) (pairing delimiters) the \( and \) are, in the first pass, skipped as you would expect, and the actual beginning and end of the quoted material (the regex) are found properly.

But in the second pass, the \ backslash is stripped away from the inner parens, as documented. The result is that the inner parens are no longer escaped. When passed to the Regular Expression compiler, what the compiler recieves is: m/(?r)?/i. And in particular, as we saw before, (?r) is a syntax that the compiler has no idea what to do with. Thus endeth the story.