The SNES development book has a very small audience, and is not intended as an eternal reference or textbook. It's meant to be used by people who can resolve errors in the document with hands on experience with the hardware, or direct contact through their working relationship with Nintendo. I don't know how many revisions it got before the leaked version that's widely available, but probably not many, if any. If there are corrections or supplemental information, these could be transmitted directly without the manual having gotten an update.
(I dunno if we should consider it lucky we have the English version, as it probably got the benefit of corrections from deployment of an earlier Japanese one... though it may have also had the detriment of mistranslations.)
So, take everything in it with that grain of salt. It's generally pretty good, and it's great at giving an idea of what Nintendo thought their hardware was supposed to do, but it was a living working document, and that's very important contextual information.
No reference is perfect. Confidence in any of this information is on a sliding scale, but here's my general pecking order:
If you want a reference that's accurate, the best bet is
the source code of a widely used emulator because you can trust that it's been tested with a lot of games and a lot of users. However, it's often difficult to read and understand source code directly.
Next after this, I would suggest a well-used wiki with a collaborative community that documents its sources when new information is found. Unfortunately.... we don't have one yet for SNES, IMO. The
NESdev Wiki is an example of this. It's been around a very long time, and it's documented and cross referenced with discussion and collaboration on the forums. The
SNESdev Wiki may eventually meet this bar, but right now I think it is too new to meet the "well-used" requirement. The
superfamicom.org Wiki on the other hand is well used, but has very poor referencing and collaboration. Its edits are anonymous, commentless, with poor documentation and no records of coordination. It has a lot of good information, but the inability to collaborate effectively makes its veracity highly variable.
Third (well, second), we have past documents from single authors like Nocash or
Anomie, who clearly put in a lot of work, a lot of revision, a lot of personal testing, and a lot of dicussion with others. These are generally very good (and often seem to be more reliable than the two wikis mentioned above). However, if anything with the wiki is wrong, we can correct it today. If anything on
FullSNES is wrong, it may never be corrected.
I'd put the SNES development document just after those, though I do consider it very important reading. It gives a lot of insight into good practices for software development that are often not addressed by emulation and reverse-engineering focused authors. Some errors are expected, for the reasons I gave above, but if you actually apply it to work that you test on the hardware, most of these errors will reveal themselves to you. (Thankfully we have the community resources listed above to compensate for a lack of direct support from Nintendo.)
Finally there's one-off documents, YouTube videos, forums, rumours, etc. There's a lot of information that might be true, but a lot of it needs verification. Some of it is just leads for further investigation.
None of this estimation is a substitute for critical evaluation. The reason I can trust so much of the NESdev Wiki is that so often it cites the forum, where I can see who documented it, and what other people had to say about it. The discussion is part of the testing process. Similar goes for BSNES' source, because I know it's been tested on many many many games by many users. I don't expect perfection from any of these sources, but real evidence of testing does a lot for confidence in the information.