Alright, you actually came in with a civil tone, so I'll try and answer this as best I can:
Short answer: Making things easy is hard.

Long answer: For the most part, people working on projects or hacking on the N8x0 are doing it for fun. They are spending their (often limited) free time. They do this because they enjoy it, because they are scratching an itch. They also have other motivations of course, but generally they are doing it because they want to; other motivations come *after* that. If a programmer/dev/hacker has time and motivation left over after completing a particularly cool trick, they often come here to brag about it and also share it with others.
Now, when they write up this info, they assume a certain background because it is easier and faster for them, not because they are trying to intentionally leave people out. If I wrote a really complete guide on (for example) how to get Debian onto an N800, I would end up with a novel that started with something like: "The plastic and metal object called an N800 has two sides, a front and a back. The front has a picture-showing device called a screen. Orient the device so that..." and so on and so on. This may seem ridiculous. Of course you don't need it simplified to that degree! But, people writing up their work have to pick a target audience. It's *easiest* for them to use the simplest terminology they can to explain what they did. They think in terms of these acronyms and jargon that they write in. It's just the same as in any profession with specific tools. This goes for programmers as well as car mechanics and doctors. As you've discovered, this puts the burden of effort on the user. In cases with beta software or stuff that's just not aimed at general users, this sometimes *might be the right way to do it,* like it or not.
A "copy+paste" howto is a kind of compromise, as it doesn't require them to explain everything they're saying, just to give exactly the commands that make it work. But still, this only works for very straightforward processes.
Now the other side of the scale is actually just the dev making a nice simple package. When someone does this, *all* the effort rests on the dev/hacker/programmer. Making a debian .deb package is actually pretty difficult. Doing it "the right way" is even harder. (You think all this stuff is hard, go read up on how to make a new Debian package.).
Not only is doing the packaging somewhat difficult, but so is automating the install process. Many times, you end up writing small programs *just to handle the installation of other programs.* This includes things like checking settings, then modifying them depending on their current state.
In the end, writing up documentation is usually mutually exclusive to time spent hacking on the program they're making. When push comes to shove, they'll get the documentation out of the way as fast as possible, and get back to what they want to be doing: making their program better or playing with their kids or going out to a bar.

Here's the fun part: What can you do?
If you hang in there and keep learning this Nokia Internet Tablet thing, you'll probably get better at using it and Linux in general. When you reach that point, look back on all the new users struggling to make things work, and *help them.* Heck, every time you have trouble doing something, then figure it out on your own, make a quick reply, even if no one has asked. For example: "I didn't know what the "cat" command was so I looked it up and found a quick explanation here: link." It *will* help someone in the future.

Sorry for writing such a long post. O_o Hopefully it helps you understand the situation a little bit. We're really not out to confuse you and I hope you stick with it. Glad to have you with us.

-John