The screensaver mode can be disabled. The enumerating thing will most likely lead apps to crash, so I am quite sure no other app is doing this, so it's safe to ignore.
"The screensaver mode can be disabled" - the first app wants to enable the screen saver. The second app wants to disable it. What happens?
"will most likely lead apps to crash" - you're a developer who's attempting to hack somebody else's app so that yours stays on top. This is a regular topic on Raymond Chen's blog - the kind of developer who does this isn't normally worried about a bit of crashing.
No, look at the real life constraints of the problem. The screensaver can be prevented from starting by using SetThreadExecutionState or moving the mouse. Another app can't stop you from making the system unidle.
And in the second part you're not paying attention to the constraints. If you want to simply kill all programs, that's easy in windows. The problem described above is to keep the system running, but become the topmost window. So a solution that causes crashes is not a solution.
Crashing a windows program is trivially easy, and it would "solve" the problem, but that's not the right kind of solution.
You could restart them all again after your program is done. Of course, if the other programs do more than just display a message, which is hopefully on disk rather than just in RAM, then you'd still have data loss, so... yeah.
I think disabling takes precedence over enabling. This is to prevent interruption of e.g. a movie the user is watching. I can't think of a use case where the user would want a program to start the screensaver even though another app has disabled it?
"setting their program as the screen saver, disabling the mouse and keyboard devices, and then invoking the screen saver on the secure desktop."
or
"enumerating all the processes on the system, attaching to each one with debug privilege, and suspending all the threads."