1. Lazy HR screeners ...
2. They may be hiring someone they've already picked out from inside the company. ...
That might happen sometimes, but everywhere I've worked, neither is the case, yet these sorts of job descriptions are still common. In my experience:
- Job listings contain a list of keywords based on what skills the ideal drop-in candidate would possess. The hiring managers know that they probably won't actually find someone who perfectly matches these skills who wants that particular job, but they list the skills on the off chance that they will.
- Resumés are pulled from a database based on keyword matching and based on which jobs you've expressed an interest in. If you don't have enough keywords, no human will ever see your resumé.
The person hired usually has at least some of those keywords in his/her resumé, thus getting the person past the initial sanity check. The person also has things in his/her resumé that catch the attention of the hiring manager who screens it next. However, the person's actual qualifications are almost never an exact match. In reality, the person hired might match 30% of the stated criteria, but they might also end up matching the requirements for some other job within the same team, and somebody else on that team might have the requisite skills to take on some of the posted job's responsibilities.
For example, consider somebody applying for an OS kernel test engineer job. The ideal candidate would have experience in writing kernel extensions, would have experience writing test harness code with a particular test harness, etc. However, the person hired might have the test harness skills, but little kernel engineering skills. That person might, however, have strong skills at writing (English), which might free up part of another kernel engineer's time that would otherwise be spent writing documentation comments in the headers. Then, that kernel engineer would have more time to help out writing the kernel-side hooks that the test engineer would need to use.
Or consider somebody applying for a documentation position. The person who left might have experience with server technologies and networking, so an ideal drop-in candidate would have those skills. However, two other documentation engineers might have the networking and server chops between them, so if they found somebody who could cover some of the technologies that those two existing people were currently covering, that person would also be an ideal candidate.
Unfortunately, there's no good way to express such a complex (and potentially ever-changing) set of requirements. Thus, my general recommendation is this: If you think you'd be good at the job, apply. If you only meet some of the criteria, apply anyway. You might or might not get the job, depending on whether somebody else is a better match, but generally speaking, in my experience, the most important criterion is not what you know, but rather how easily you learn new things. With the exception of highly senior positions, everything else is at least to some degree optional.
Obviously, different companies hire differently, so YMMV, but this is usually a good general rule.