Unfortunately, it was necessary from a security perspective. We saw a number of papers on Just-In-Time compilers come out for other products over the last year that we concluded were relevant to the PixelBender JIT. Rather than wait until an emergency to do something about it, we chose to take action to ensure that your customers and other end-users are protected.
We performed a careful analysis and concluded that the mitigations necessary to defend against this emerging class of attacks would damage performance almost as badly as disabling the JIT, while still leaving possible attack surface. We also determined that Alchemy and Stage3D are not vulnerable to these classes of attack, which is why we're recommending migrating your content to take advantage of them.
While we would have really liked to pre-communicate the changes, we would inherently have to describe the potental attack vector publicly without shipping a fix. We've experimented with pre-communicating security changes in the past, and found that attacks against those features were quickly developed and deployed by bad actors.
Backwards-compatibility is always a primary engineering goal, but the fact is that the threat landscape facing the web has evolved significantly over the last decade, and adapting to it frequently requires choosing one of a number of terrible available options. While we understand that this is tremendously inconvenient for developers relying on PixelBender JIT for performance, we strongly believe that it was the best of the available options.