Apache 2.4 is technically better and many commonly use components have been pulled into the Apache core, which had to be manually compiled before, but pulling in some modules and changing them for Apache 2.4 broke compatibility with said external modules, ie. importing mod_proxy_html but not mod_proxy_xml, but having a different API and default charset etc., also using an external mod_proxy_html/xml for compatibility is not possible due to conflicts with the internal one.
But IMHO the problem is mainly that if you have a legacy web site / reverse proxy, or a site which requires particular versions of a custom Apache module (mod_perl comes to mind) you need to stick with 2.2.x, until the third party module SW is upgraded. This not a reflection on the Apache team, only that software dependencies are sometimes complex, and many modules are supported by free by third parties in their spare time (or not) and need to be patched significantly for significant changes in api. There can be up to 2 layers on to of Apache, all with their own API compatibility issues at each level, not to mention the dependencies of Apache itself.
The content creation model is often to make a web site as a single pay for development item, and then host it as an ongoing item, the hosting not related to the individual developer. So the site needs to be deployed on a server version which has a compatible ABI as it was developed against, as the hosting organization likely has no relationship to the original developer. This prevents the application being upgraded without having a relationship to the original developer (and related SW stack).
Companies who manage a whole stack of application(s), and also host them are pretty rare these days. Most apps get hosted on commercial web hosts. There is no impetus of the original developer to upgrade the site, as they are working elsewhere.
