Correct, a manual shutdown PREVENTS all of those things related to saving "the current state of your system" from taking place. It is therefore "drastic."
There is a wide spread understanding that by simply trashing (moving to the Trash) a plist file ,it is automatically re-created on re-launch. This understanding is "mostly" correct for APPLICATIONS. But Applications are different from the Operating System itself, even one structured on a layered kernel as opposed to a monolithic kernel.
It is only a correct understanding for Applications which are in fact, completely quiescent (i.e. not running) at the time when a plist file is deleted! "Obviously," if you delete the plist file from a RUNNING application, the contents of that file are in RAM and will be written back out when the application quits.
One problem here is that by simply moving the plist file to the trash, and even emptying the trash, it does not "disappear" to the application. The location of that file is governed by the file location information contained in the application's RAM -- i.e. the program has no knowledge that you moved the file to the trash and then "emptied the trash." Consequently, when the Application is quit, it simply re-writes the contents of its RAM to the "last known" location of the plist file.
The second problem is that because the program is running, the CONTENTS of the plist file are known to the application. Unless there is specific code in the Application to CHECK for the existence of the plist file on termination and therefore re-create an EMPTY plist file, an Application will simply write out the information for the plist file currently contained in its RAM.
Most all Applications contain a "start up check" (on application launch) to see if this is the "First time" being launched, and therefore no plist file exists, so a "default" version should be created. This is why:
1- Quitting the application,
2- Moving the plist file out of its expected location (to the trash or anywhere)
3- And then relaunching the Application
will recreate the Application's plist file.
The difference with the OS is that OS Applications (like networking) are NOT quiescent -- they are in fact loaded into RAM in "known locations" and stay there until shutdown. During a "normal" shutdown, restart or sleep, (especially now in OSX) the OS attempts to "save state," so that it can recreate "the state" of the environment when shutdown occurred on reboot. (Reopening all of those apps you have open and all of the documents you were working on.) This "state saving" is why Shutdown takes so long. Power cycling the system also guarantees that RAM is wiped -- Power Cycling also runs the POST (Power On Self Test) which does not run on any restart or "normal" shutdown and reboot operation.
So, in short, your understanding of plists is correct for Applications, but "not quite" correct for the Operating System plists. (Knowing which plists this applies to is an arcane piece of knowledge requiring extensive training in the Black Arts!)