On the subject of Noesis in particular, it definitely lacks good (and occasionally any) documentation. The tutorials chrrox has done have been a huge boon to it, though. It's on my todo list to start going down the API functions and making real documentation and examples for each one as well. I'm a bit more motivated to do that, now that I know people actually care and are willing to write their own Noesis scripts.
I've personally been writing games and game engines for the last 15 years, and I've done a lot of work on commercial stuff (going all the way back to the Soldier of Fortune and Jedi Knight 2 days...and even a little stint with Crytek many years before they finally managed to ship a title, haha), and I've rolled my own engines for quite a few platforms/generations now. So Noesis is definitely structured to make sense from a game developer's point of view, and to accept and understand data in a way that is flexible but lends itself to common real-world data and storage conventions typically employed in actual games.
Rendering methodology has changed a lot over the years, and there are specific ins and outs to be aware of for each system (hardware vertex flags for the PSP, VIF code for the PS2, various forms of texture twiddling/tiling that Noesis luckily takes care of on a good range of platforms now, and the list goes on and on), but Noesis tries to cover all the bases to make sure that actually feeding the data in is as painless as possible no matter what kind of data you're dealing with. Again, though, without experience working with and writing an engine for the specific system you're digging into model data for, you've got a lot of learning ahead of you, and even then, sometimes developers are just insane and do insane things. The most recent case in point is FFXIII-2 storing its mesh UV's in its texture bundles.
When it comes to compression and animation, developers often defy any sense of standards, and the only way to really figure that data out is sometimes to disassemble the original game code. Sometimes you even need to go this far to fully understand a model format, depending on how completely you need to understand it for your needs, and on the complexity/deviations-from-standards in the format itself. It's a real pain in the ass for the newer systems when you're in my boat and you can't actually use an online debugger (I've only resorted to decrypting and reading disassembly offline for a couple of games on the PS3 and 360 for this reason, and just found out the old xex decrypter I've been using is out of date again), but for systems like the PS2 where we have working emulators, if you have the patience and enough accumulated knowledge, you're pretty much guaranteed to find what you're looking for eventually. Understanding disassembled code is a skillset all its own, though, and on top of this you're dealing with a new/different set of instructions for each different CPU architecture. On the PS2, for understanding model data, you're likely to spend more time having to read through VU instructions than MIPS instructions.
I think the PSX era of games is really bad about standards in general, or really anything that came before fixed function pipelines were the norm. Understanding and recognizing VIF tags is of great assistance for PS2 games, but for PSX games, where doing your own transforms and sorting was mandated and there weren't even libraries to enforce anything resembling data standards for quite a while into the PSX's lifespan... well, there don't tend to be any real standards to follow, so you're often going to end up either disassembling code or spending a reallllllly long time staring at that binary, or both. And as mentioned, even on platforms where you're going to need your data to follow a fairly predictable pattern at some point, developers still do insane and inefficient things that just don't make sense, and end up converting their own data (usually rather pointlessly) at runtime.
But at least in the end, when you figure out those really crazy formats, you get bragging rights and you can have fun trash-talking the developer for all of their crazy and bad decisions.
