If I were deciding, I would be inclined to reject this.  Part of the understanding when enums were added was that they would not automatically be used in the stdlib anywhere there could be used.

To answer 'why not', there is an obvious gain to naming arbitrary numerical code, as with HTTPStatus.xyz.  I do not see any gain from replacing 'GET'*  with HTTPMethod.GET.  Just more work to write and read.

*Does http require uppercase for the methods?

To answer 'best practice',  I disagree with the premise that 'hardcoding' such short meaningful names is bad.  I think that this is a mis-application of a sometimes valid principle.

If people who do like such replacements are changing spellings, other than to lower case the words (enum value do not have to be uppercase), in the process, shame on them. Otherwise, typing HTTPMethod.OPTIONS is harde to type correctly, not easier, than 'OPTIONS'.  If you posted evidence as to your claim, I might be more favorably inclined.  On the other hand, if everyone used the quoted strings, 'GET', etc, there would be no problem with inconsistency.

My personal experience with turning constant strings into constant names is with tkinter, which has about 50 assignments like "E = 'e'", "RAISED = 'raised'", and so on.  I consider them more a nuisance than a help.  CAPS are harder to type than letters, and they give TOO MUCH EMPHASIS to rather minor configuration issues.  If one does 'import tkinter' or 'import tkinter as tk' instead of 'from tkinter import *', then "relief=tk.RAISED" is definitely harder to write as "relieve='raised'", and to me uglier.

To me, your later throw-in comment about static analyzers might be the most persuasive point you made