Sorki, ale to dalej jest modyfikacja core, z doświadczenia wiem że takie nietypowe zabiegi źle się kończą wcześniej czy później. Stosowanie takich nietypowych zabiegów jest nieintuicyjne, nieczytelne i jest to zła praktyka. Ktoś kto odziedziczy po nas taki kod będzie życzył nam losu Prometeusza, ciekaw jestem kto chciały odziedziczyć taki nienaturalny kod a potem szukać czemu coś działa inaczej niż w dokumentacji i inaczej niż autor chciał.
Nie neguję w tym momencie samego pomysłu, a sposobu realizacji. Dużo lepiej jest to zrobić w formie pluginu. Wydajnościowo wyjdzie na to samo.
Tak o ile bot w ogóle sprawdza co dostał, a nie sprawdza tylko czy dostał już klucz sesji, a jak nie to dokonuje kolejnej próby (ten scenariusz jest bardziej prawdopodobny bo mniej kodu trzeba napisać).
Nawet jeśli dasz to zaraz na samym początku pliku jeszcze przed includami wp to nadal przekazujesz obsługę żądania do PHP, czyli musisz utworzyć nowy wątek do jego obsłużenia - zarezerwować pamięć, przydzielić moduły, wczytać plik żądania i go zinterpretować. Oczywiście można tak zrobić. Jednak ja uważam, że w przypadku problemu o którym mówimy czyli zabezpieczenia się przed botami atakującymi strony logowania/panele administracyjne metodą brute force nie tylko trzeba zablokować możliwość łamania danych logowania, ale i minimalizować straty w postaci obciążenia serwera jakie te boty generują. Tutaj trzeba zmniejszyć zapotrzebowanie na zasoby serwera do obsługi takich żądań, a na serwerach WWW zawsze najkosztowniejsze angażowanie w obsługę żądania parser PHP. Z tego też powodu stosuje się ModSecurity dla całej witryny.