Windows context menu handlers can be both static as well as dynamic. If you're interested in delving into it further, I advise you to read the Shortcut (Context) Menus and Shortcut Menu Handlers article, especially Choosing a Static or Dynamic Shortcut Menu Method and Customizing a Shortcut Menu Using Dynamic Verbs.
Quoting from this Visual Basic Shell Programming book excerpt:
Dynamic Context Menus
Static context menus are limited because they are the same for every
file object of a given type. Also, the number of files that can be
processed through a static menu is limited by the program that is used
to carry out the command. What if you need to process 20 files? What
if you need different processing options based on the state of the
file itself? There are also situations where you might need one
context menu for a group of files and another for a single file. This
is where dynamic context menus come into play.
You might want different menu items displayed based on whether one or
multiple files have been selected. Since the number of files selected
can be determined in IShellExtInit::Initialize, this becomes a trivial
matter. You also have the ability to base the menu item on the file
itself. In addition to the number of files selected, you would also
already know the filenames in question. This means you could open
the file, retrieve information, and base the menu item on actual
data. Or you could examine some other attribute of the file (such as
its creation date, its size, or its read-only status) and base the
menu item on that information as well.
Finally, if you want proof that the file is actually being read by WinRAR's shell extension DLL (since you seem to doubt it), here are the various ReadFile calls registered by Process Monitor on simply right-clicking a WinRAR SFX:
(The process name is displayed as explorer.exe and not rarext.dll, because the context menu handler is an "in-process" COM object that the shell loads directly into explorer.exe's memory space for execution.)
As you can see, it reads the first 7 bytes to confirm that it's an EXE:
After reading more data (no doubt to obtain and parse the header), it then reads 7 bytes from offset 101,376 to confirm that it's a WinRAR SFX and not just any old EXE:
This prompts it to add various context menu entries such as Open with WinRAR, Extract with WinRAR and so on, which don't get added for "normal" EXEs.
Furthermore, in WinRAR's Settings dialog there's an option titled Where to check for SFX archives:
Here's what the help file has to say about it:
"Where to check for SFX archives" options control processing of SFX
archives in context menus. Checking contents of executable file and
detecting if it is a self-extracting (SFX) archive introduces some
delay when right clicking every ".exe" file, because WinRAR needs to
read and analyze file data to find out if it is SFX. While such delay
is negligible for fast local hard drives, it can be noticeable in case
of slow network disks. This group of options allows to enable or
disable SFX processing for local hard disks, network disks and other
disks like CD-ROM and USB separately. If you turn these options off,
you will not see all SFX related context menu items when right
clicking SFX archive. So disable these options only if you really
experience delays when right clicking ".exe" files.
Hope that puts your doubts to rest. :) As for your second question about whether extensions have "less importance" now and lack "any influence in context menu[s]", I don't understand what you mean. Even image/video thumbnails are generated by shell extension handlers (DLLs). A list of different handlers can be found here. As you can see, it's possible to have custom shell extension handlers for everything ranging from shortcut menus, drag & drop operations, icons, icon overlays, property sheets, thumbnails, infotips, metadata, Explorer columns, copy/move/delete/rename dialogs, search...
Edit: Coincidentally, Raymond Chen happened to post an article about shell extensions today as well (don't forget to read the previous one too).