Even within an SDK, why would you have two separate libraries that do the exact same thing? That is just asking for trouble especially if they use the same namespaces.
Secondly, how would fixing the tool suddenly fix the issue via a patch to the consumer? This is logically incomprehensible. The fact that the games with the AF issue got patched to fix it means that there was something with how the developers were calling the function from within the game.
Thirdly, if the game's AF issue could be resolved with a patch from the developer and there was no firmware update on the consumer's end, then this is entirely an issue from the developer's side and that there was a problem with how the developers chose to call the AF function.
EDIT:
I guess the better question is how large were the patches that were deployed to resolve the AF issue?
I'm not necessarily talking about libraries, it could be a fault from a conversion tool a developer might have used, but there is no real reason why every developer needs to use the OGL libraries that are in the SDK.
If it's a conversion tool, then subsequent games will stop suffering from this altogether. Developers would still be able to attempt to fix the issue manually with a patch. If it's a library, the game can be recompiled against these updated libraries and the issue can be corrected though QA is the hard bit there.
These libraries would usually be included on the game disk not on the system software so it would be an issue of patching the game rather than the system. If the issue is with the system then Sony needs to introduce an update.
For developer responsibility it is a question of whether you consider a developer not using a potentially expensive work-around over hoping the issue will be resolved is their fault or not. Business realities often dictate that unless the fix is free developers might simply ignore them.