Thank you for the link! Having now read that, I've learned a few things.

• An expression without /o does indeed not recompile if it hasn't changed, but there's still an overhead of comparing the "new" string to the old string to decide whether to recompile. In my tests, my strings are kind of long (1_000 characters), so this overhead is more apparent.
• The /o on a qr actually does do something—something just like it does on any other match.
• A literal qr actually gets compiled at compile time. That shouldn't be a surprise, but I didn't know it.

Looking at my test results some more, I guess my anomalous case was one where matching took an extra long time, and the overheads got washed out of the results. Since I told Benchmark to run a fixed number of seconds rather than a fixed number of iterations, there were fewer iterations and less overhead resulted. That makes the "compiled once" qr constructs look about the same as the "compiled once" m//o.