When to include a revision identifier (version, iteration, specific name depends on company/industry practice) can be determined based on how you should read the reference.
In the case of the semi using a revision identifier is actually useful, as an update of ISO 9000 to a newer revision at the factory does not mean the semi in the field automatically meets the claim of being built in compliance with these new requirements. (I do agree they should use the correct revision for the system under which it was built

).
The same holds for the essential requirements. If you use it in submission, then it is your claim that it complies (present tense) with these standards, and thus specific revisions are important. It is not a plan or intent document (e.g. checklist). If a standard you claim compliance with updates, you usually cannot substantiate your claim for compliance to the newest standard immediately. If you split revisions off to a seperate list, then be careful of this effect. Updating the revisions in that list before implementing changes effectively means you are claiming compliance where you are not compliant. There's no need to explain to anybody here the trouble that can land you in.
- Thus if it is a intent (plan) document that will call upon the then current/applicable revision an undated/unrevisioned reference is appropriate. These do entail checking for, interpreting and adjusting to the latest changes/current state every time you use it, and thus is good for process map (procedure) level matters and low frequency use.
- If it is an 'aligned' document (e.g. work instruction to a test standard), for which the check, interpretation and adjustement took place at review/approval, then a dated/revision reference is appropriate.
- Come review time, the reviewer should check whether the use of that specific revision is appropriate. Sometimes you would not updated to the latest (e.g. testhouses needing to be able to test to both/either 60601-1 edition 3.0 and 3.1 for their customers due to jurisdictional differences, thus having split instructions), generally you should do so. This is (partly) why you are expected to define review periods for documents.
- You would control external documents (such as standards) on their status, and if that system indicates an update you would look for these kinds of instructions and review them to assess whether they need updates as the previous point, but sometimes before that instruction's specific review period is up.
- Note that general interpretation (see Marcello's link) says: "If the referenced document is amended or revised, the dated references to it will need to be reviewed to assess whether they should be updated or not." Thus you need a robust system which not only looks for regular revision updates to the external document, but includes associated corrigenda and amendments.
- Claiming compliance to an unrevisioned reference in a procedure (e.g. EN ISO 14971 in the procedure) without claiming a revisioned reference (EN ISO 14971:2012) in an underlying instruction opens up the possibility that you will be found non-compliant with your claimed unrevisioned reference. (Good example warning, as (EN) ISO 14971 is expected to be updated in a few years. I'm expecting to hear some of these pop up at that time again.
)
- If it is a record, then a dated/revision reference is practically mandatory, as you cannot change the past to conform to future states (as implied by undated/unrevisioned reference).
- Certain reports covering time ranges/analyses may block off time ranges and their related revisions or simply refer to the general topic through an undated/unrevisioned reference, but thus cannot build on the dated/revision dependent content.