[Initially written before you posted the PR]
Serhiy's result suggests that 25 might not always be enough and he suggested 50.  Plus IDLE sometimes makes more calls internally.  Lets go with at least 30.

I agree that "get...(set...(n)) == n" (when n is positive, a check we should emulate) and "set...(get...())" leaving limit as it was are desirable.  The docs and docstrings just need to say what we do.  Possible additions.
"This IDLE wrapper adds 30 to prevent possible uninterruptible loops."
"This IDLE wrapper subtracts 30 to compensate for the 30 IDLE adds when setting the limit."

The main reason I can think of for users to play with low recursion limits is to explore the implementation.  They simply cannot get stock CPython behavior when running with IDLE.  So I want the IDLE wrappers to not be completely transparent. For that to be obvious in calltips, the first line should say so.

The main reason I want to intervene is to prevent the not-nice behavior of hanging until a manual restart.  I checked, and it is still possible.

In 3.8.0b1, the min n is not 1 but current stack + 5.
>>> sys.setrecursionlimit(11)
Traceback (most recent call last):
  File "<pyshell#9>", line 1, in <module>
    sys.setrecursionlimit(11)
RecursionError: cannot set the recursion limit to 11 at the recursion depth 6: the limit is too low

Our increment will prevent a user from seeing this, but this is necessary to prevent ...

>>> sys.setrecursionlimit(12)
# hangs, once after printing "Exception ignored in thread started by"
# until manual restart.
# 18 hangs after printing 60 lines of a double exception.
# 20 does not hang and calling 'f' from the original message
# gets a truncated traceback ending with
   [Previous line repeated 12 more times]