No they aren't. There's no central webkitd or anything like that. WebKit is a framework, not a background daemon. If you quit all apps that use WebKit, then no associated processes will exist anymore. If you look in Activity Monitor all the web content processes are parented to launchd(1), but if you ask launchd about it, it'll tell you that the "responsible pid" for each web content process is the WebKit-enabled application that spawned it. And if you quit the application, all the associated web content processes shut down.
So, quit all of the WebKit apps and then check to see if WebKit libraries are still loaded. I posted instructions further down the thread, it's not hard to see for yourself.
If I quit all WebKit apps then by definition I've quit everything that loads the libraries.
You also seem to be very confused as to the difference between a library and a process, given what you've been saying. Having a bunch of apps using WebKit as a framework does not confer any kind of advantage on these apps. If I have an app using WebKit, and you have an app using WebKit, they don't affect each other in the slightest. The only way they would is if they were reusing shared web content processes and so didn't have to wait for those to launch, except a) I imagine launching a web content process is pretty quick, and b) they don't share web content processes so it doesn't matter.
So, do it. See what happens; WebKit is still loaded via MacOS because it's used to render UI elements that are considered part of the system. Unless you've modified the way default apps run on MacOS, WebKit should be loaded into memory from the moment you boot MacOS to the moment you shut it down.
The overhead of mapping the files on disk into memory is pretty minimal. The framework still has to be initialized anew for every application. About the only benefit I can think of is WebKit might be in the dyld shared cache (assuming that includes frameworks that can be updated independently of the system), and that just means it would bypass some of the dyld setup, but if so that would just have a minor effect on the launch time of the application.
Also if I actually do that right now I see a bunch of WebContent processes, the apps themselves and then there are a handful of daemons that have InfoPlist.strings open from WebKit (from the iOSSupport subsystem) but that's just a localization file and I don't know what it's doing there but it appears to be completely irrelevant (the daemons do not have anything else from WebKit loaded).
AFAIK macOS does not use WebKit to render UI. iOS has been known to use WebKit for text rendering in the past, but I'm not sure if it even still does that, and that was presumably in-process anyway. And even if it did that still wouldn't matter as far as applications' own use of web rendering engines is concerned.
Those aren't the OS, those are individual apps that have chosen to use a web rendering engine for various content, and it's not even correct. Calendar doesn't use WebKit at all and never has. Mail.app uses it to render external HTML input (i.e. email messages) rather than UI. I believe Music.app moved off WebKit some time ago as well, and it looks like App Store did too (Accessibility Inspector confirms that the Updates page, which used to be rendered with WebKit, is now a collection view). Both Music.app and App Store link against WebKit but that's likely because the Account Settings page is rendered with WebKit (this is likely content that is served remotely).
In any case, the OS itself does not rely on WebKit for UI, it just ships some apps that use WebKit.
