Respostas:
Eu posso dizer com cerca de 99,9999% de certeza de que o WordPress nunca se tornará completamente OOP na versão futura, a menos importante é que o tópico apareceu várias vezes na lista wp-hackers e os membros da equipe principal não manifestaram interesse em fazendo isso.
Ao olhar para minha experiência pessoal com programação e ensino de OOP a partir de 1990, concordo com a equipe principal e acho que OOP completo seria um erro. Embora eu tenha sido um fanático por OOP e pensasse que era uma panacéia, desde então acredito que ele tem seu valor em alguns contextos, mas em outros contextos ele atrapalha.
Um dos maiores problemas que encontrei com o OOP é que ele força o desenvolvedor a criar uma estrutura muito antes de o desenvolvedor entender realmente o que essa estrutura deve ser, o que leva ao frágil problema da classe base .
Obviamente, para aspectos selecionados do WordPress, o OOP faz muito sentido e, se você estudar o núcleo, encontrará essas classes; Widget, List_Tables (em 3.1) etc.
Neste momento, estou feliz em trabalhar com o WordPress em um paradigma que não seja OOP e acho que, se tivesse sido puro OOP, o WordPress nunca teria ganho o seguinte. Por quê? Como o OOP teria aumentado a complexidade para os possíveis desenvolvedores de temáticos e plug-ins do WordPress, e provavelmente resultaria em um aplicativo que não era flexível o suficiente para evoluir à medida que a equipe principal aprendesse mais sobre as necessidades de seus usuários no passado 6 anos.
FWIW.
Muitos componentes do WP são reescritos no código OOP a cada nova versão, e novos componentes tendem a utilizá-lo (por exemplo, a WP_Customizercoisa). Mas se você está perguntando se o WP mudará sua arquitetura para uma arquitetura totalmente orientada a objetos - então não, não há informações que sugiram isso.
Eu não iria tão longe para dizer que isso nunca vai acontecer, mas é improvável que isso aconteça no futuro próximo, e provavelmente não por causa do problema da "classe base" :)
Primeiro, existem apenas desvantagens no uso de código processual sobre o OOP para um aplicativo CMS como o WordPress, simplesmente porque esses aplicativos devem ser estendidos através de plug-ins. Jogar uma combinação de funções e variáveis globais não facilita nada. Na época em que o WP foi escrito, ninguém poderia prever o que seria o WP e muitas más escolhas foram feitas. Agora é muito difícil recuperar o atraso, porque a maioria dos plugins e temas para de funcionar corretamente. A implementação de uma enorme camada de compatibilidade para evitar isso provavelmente reduziria a velocidade do WP e aumentaria ainda mais a confusão entre os desenvolvedores. Pense também no objetivo - facilitar a vida dos desenvolvedores, às custas dos usuários?
Se isso ajudar - uma discussão muito antiga sobre os wp-hackers, mas ainda relevante para esse tópico, e uma ideia proposta pela comunidade, agora marcada como "território do plug-in". Não notei outra atividade nessa direção recentemente.