Reviewing the Linux source, I don't see any reference to EFI SBAT or dbx - so I can confidently state that with just Linux, it is impossible to render windows unbootable (besides, it'll just panic() when it can't find find systemd; https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/init/main.c#n1523).
The only relevant code I can find is; include/linux/efi.h block/partitions/efi.h and drivers/firmware/efi/* which contains functions for interfacing with EFI and mounting the EFI partition, but those drivers don't seem to make changes until the EFI partition is mounted, or a command is made via the /sys/firmware/efi/efivars/ interface.
systemd of course does interface with EFI; https://systemd.io/BOOT_LOADER_INTERFACE/
According to this wiki page from Arch systemd/Linux; https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot to make changes to the dbx, you can either use "sbsigntools" or efitools (both of which depend on gnu-efi - which isn't a GNU package, but claims to be "using the GNU toolchain").
As for SBAT, I couldn't find any software or scripts for the updating of such, only instructions for using GNU objcopy to add a SBAT to software that is to be installed into the EFI partition; https://github.com/rhboot/shim/blob/main/SBAT.md?raw=true
As far as I can tell, there is an absence of scripts that will actually touch anything EFI in relation to windows (although there is a script in windows that will render old versions of GNU GRUB unbootable that usually gets automatically executed) - so to render windows unbootable via such programs would require the user to choose to input carefully crafted commands - really the user would be better off firing up gparted and deleting any partitions containing malware, same as any malware .efi files in the EFI partition - allowing them to enjoy extra storage space on the systemd OS.
Re: Why is it up to Microsoft to take care of MY computer's security?
The only relevant code I can find is; include/linux/efi.h block/partitions/efi.h and drivers/firmware/efi/* which contains functions for interfacing with EFI and mounting the EFI partition, but those drivers don't seem to make changes until the EFI partition is mounted, or a command is made via the /sys/firmware/efi/efivars/ interface.
systemd of course does interface with EFI; https://systemd.io/BOOT_LOADER_INTERFACE/
According to this wiki page from Arch systemd/Linux; https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot to make changes to the dbx, you can either use "sbsigntools" or efitools (both of which depend on gnu-efi - which isn't a GNU package, but claims to be "using the GNU toolchain").
As for SBAT, I couldn't find any software or scripts for the updating of such, only instructions for using GNU objcopy to add a SBAT to software that is to be installed into the EFI partition; https://github.com/rhboot/shim/blob/main/SBAT.md?raw=true
As far as I can tell, there is an absence of scripts that will actually touch anything EFI in relation to windows (although there is a script in windows that will render old versions of GNU GRUB unbootable that usually gets automatically executed) - so to render windows unbootable via such programs would require the user to choose to input carefully crafted commands - really the user would be better off firing up gparted and deleting any partitions containing malware, same as any malware .efi files in the EFI partition - allowing them to enjoy extra storage space on the systemd OS.