I'm surprised there hasn't been much response to this announcement.
On the other hand I think it's far too early to draw any conclusions, even in the next few months. Flash 11 and AIR 3 have only recently been publically released and it will take some time for it to become part of the real world landscape. Indeed it will take more time than previous releases of the Flash pltform. There is a steep learning curve involved for a lot of developers when it comes to 3D and many will be holding back on climbing that curve until there are some stable frameworks to help them. And framework developers will have been holding back on commiting to something like PB3D until it was more of a public release/standard.
Clearly something like PB3D will be required - ie. a high level shading language. But if it's not PB3D it will be something else. There is no doubt about that.
Now there is some community work being done on alternatives. The first alternatives are going to be (or already are) attempts at AGAL compilers for existing shader languages: Cg/HLSL/GLSL (which I'll collectively call SL). This was obviouly going to happen irregardless of PB3D, if only because there is an existing body of shaders (and knowledge) already concocted in such languages. On the other hand PB3D is sufficiently similar to SL that you wouldn't necessarily need to write an AGAL compiler for SL. You could manually rewrite an SL shader to PB3D, or otherwise explore a simple SL to PB3D parser. And compile to AGAL from there.
In addition to community alternatives there is also some company work being done. The Unity 3D framework team have made an early commitment to producing a Flash Export option in their 3D framework (and not just binary export but code export as well). And since Unity already has support for existing SLs, then those using Unity wouldn't ever need to touch something like PB3D.
But on another front, and this is somewhat counter-intuitive, there are a number of developers who have actually warmed to writing shaders directly in AGAL, or learning how to do that. While it might have started out as a necessity, there is also the security in knowing that AGAL is now a permanent feature of the Flash 3D pipeline. One can afford to spend time learning it, knowing that it's out of the labs and in the real world, ie. that it's not going to evaporate. One can make a commitment.
This sort of thing is not to be underestimated.
Until PB3D becomes (or at least promises to be) an official release, adoption by developers is going to be tentative. Non-commital. A maybe. And with PB3D management being in the same tentative state - that's two "maybes" depending on each other for something more than a maybe - the result of which can only be (surely) a collapse of commitment on both sides.
But where would PB3D go if it continued development anyway? Does the spec require more work? Probably not. It's a good spec. That leaves the implementation. Certainly there is some remaining work to be done on the implementation. But being an experiment there isn't necessarily any need to complete an implementation. In that scenario, what might be useful is if the spec was made open to third party implementations. The spec itself is really quite good. But that's just me saying that. Would anyone commit to a third party implementation? I probably wouldn't. I don't have the time. What would be required is not just a completed implementation but a competitive implementation - ie. one that generates highly optimised AGAL bytecode as well as (or better than) any other SL to AGAL complier could. That's where PB3D would have takers.
Now the spec itself, while good, does have some limitations. This would not necessarily be appreciable until you started trying to use PB3D to solve real world problems. If you look at how a shader language has evolved in Unity (for example) you see that a macro language has evolved around traditional SLs. The macros act as shortcuts (ie. quick dev time) when in a tight corner. How might PB3D be reframed in terms of a macro language? Would we have to see otherwise nicely colour coded PB3D turning an homegenous red inside CDATA tags?
PB3D is a necessity. Or it's equivalent. Even incomplete ones.
I have a feeling that the Macro Assembler blogged about here will probably become the default way of writing AGAL shaders for now: