В чем реальная польза от соблюдения R1705 в pylint? Действительно ли код безопаснее?

Если вы пытаетесь соответствовать Стиль кодирования Mozilla или похожие тогда R1705 имеет смысл. Цитата:

Don't put an else right after a return (or a break). Delete the else, it's unnecessary and increases indentation level.

В противном случае вы можете отключить это предупреждение. А еще лучше переключиться на flake8, который имеет тенденцию оставаться довольно тихим, если вы пишете разумный код.

За пределами сообщества Mozilla, большинство людей предпочло бы видеть простые параллельные функциональные предложения обрабатывается с помощью else, например:

def max(a, b):
    if a > b:
        return a
    else:
        return b

Этот сообщение дает два разных случая для этого проектного решения:

1. Охранные оговорки.

   def try_something()
       if precondition():
            result = compute_something()
            return result
       else:
            display_error()
            return None
   

Автор утверждает, что для нескольких таких условий их инверсия и implicit else лучше:

    # Implicit else, inverted condition
    def try_something():

        if not precondition_one():
            display_error_one()
            return

        if not precondition_two():
            display_error_two()
            return

        result = compute_something()
        return result

2. Симметричная оговорка.

   # Explicit else
   def check_link(link) -> bool:
       if is_internal_link(link):
           return check_internal_link(link)
       else:
           return check_external_link(link)
   

Я согласен с автором, что здесь явно лучше.

Я бы также процитировал комментарий из этого поста, в котором говорится, что этот выбор является выбором парадигмы:

1. "Explicit else": "if-then-else" is treated as lazy computation and more suited in "functional-first" environments. If this "if-then-else" is applied to large datasets and code in F#, Scala, Haskel, Closure or even SQL - explicitness is preferred. Most probably language/platform itself will encourage to write "pure" code and discourage/make near impossible to make imperative stunts.
2. "Implicit else/(explicit return)": computation depends on 100% on side-effects and result is combination of side-effects too. It's impossible to guarantee correctness in strict sense anyway, so explicit return becomes clear declaration: "Because of laws of physics in our Universe, this computation could work incorrect. In majority of such cases this default value will be returned".