Content blockers seem to work on 32-bit devices if you compile for them:
"Yes, but I'd guess it's an arbitrary limitation—at least it seems to be for A6 devices.
BlockParty works perfectly on my iPhone 5C and apparently on @wadetregaskis' iPhone 5, both of which are 32 bit A6 (and not officially supported). I get all the relevant menus, and it does block ads (even the huge easylist conversion works, albeit poorly)." [1]
Apple chose not support 32 bit devices in their blocking API, which isn't too unreasonable. I imagine it kept the code quite a bit cleaner (or avoided having to run parallel implementations to get good speed).
As the parent says, the API works fine as is, today, on 32-bit devices - you're just not allowed to submit code to the App Store that takes advantage of this. There is no JIT or anything else inherently architecture specific in the WebKit content blocker implementation. Thus the restriction comes either from a semi-arbitrary determination of the speed of Apple's first 64-bit processor, and/or the amount of RAM that came with it, as the boundary below which content blockers might cause unacceptable performance regression (despite their /improving/ performance on many sites)... or from some odd marketing plan to sell newer devices. Hard to say which.
Personally, I doubt it's a marketing thing. Apple do sometimes restrict software features to specific devices (Siri when it launched originally), but this is rather oddly processor-dependant. So I assume it's a performance thing.
Modern designer and UI experts demand better--really worse--UI than the moon lander had[0]. This can make almost any project harder than landing on the moon.
