"prevent injection of a driver that can divert all my shit at the kernel level" is exactly what you want secure boot protecting you from.
The only thing Secure Boot is doing here is preventing you from loading a driver not blessed by Microsoft. They would happily bless "a driver that can divert all my shit at the kernel level", but it costs too much for the maintainer of WinDivert.
It is kind of sad that no one seems to bother enough to actually learn how to use Secure Boot to their advantage. Everyone is just disabling it the first time it gets in their way. Reminds me of how Firewalls used to be treated like 20 years ago. Yes, by default most implementations will only accept signatures from Microsoft. But the thing is: You can always enroll your own keys. My Laptop is currently booting a non-mainline Linux kernel with secure boot enabled. Just enroll your own Certificate and (automate the process to) sign binaries yourself. I really wonder why no one yet started some kind of project to provide a "community trust root" of some sorts which you could enroll on your machine.
I think that for the vast majority of threat models, the insecurity of having your own signing certificate (it needs to be hot if it's going to be automated) is not much different from the risk of not having secure boot at all. Also, the effort v. security balance.
The only thing Secure Boot is doing here is preventing you from loading a driver not blessed by Microsoft. They would happily bless "a driver that can divert all my shit at the kernel level", but it costs too much for the maintainer of WinDivert.