I am not an Urbit enthusiast but I did spend some time back in 2015 trying to grok their docs. So I was able to read this doc successfully. (It is exceptionally well written for such an obscure topic, one which is often intentionally obfuscated.)
Urbit terminology is obscure, probably intentionally so. (As an example, Urbit picked 0 = true and 1 = false, just because it's different than what you're used to.)
Nock is a virtual machine that defines only a few primitives. If I recall correctly, there is no "add," only +1. If you want to add 2, run +1 twice. The intent is that the VM is so impossibly simple that there is nothing to add. Just express whatever new semantics you want in terms of the frozen core.
A "jet" is a JIT-compiled version of a Nock expression, via pattern matching. The expectation is that the Nock interpreter will notice common patterns and execute some identical, but faster, computation under the hood to evaluate a jet. To continue the example, repeated application of "increment" could be lowered to the machine's add instruction. (However, I was under the impression that the pattern matching happened automatically, but it apparently involves Nock primitive 11, which is... less elegant. Sounds like Plunder gets this part right.)
Hoon is a small language on top of Nock ("typed Nock" if you like, but I understand that also macro-expands to pure Nock). I find it absolutely impossible to read because it makes extensive use of sigils ("runes"). A gate is a Hoon function. An arm is basically a member method or namespace member function. You get the idea.
The article does a good job of using the more-standard term to describe the remaining pieces: arvo (kernel), vane (driver), etc. Since Urbit is so opinionated on these, my prediction is that eventually someone is going to steal one or two Urbit terms to describe something another system does - probably "jet" if I had to guess - and that will be Urbit's ultimate legacy.