So I don't see what Secure Boot adds here on top of protecting firmware, bootloader settings and root account. Could you please give an example of an attack that is countered by Secure Boot?
So, first things first: obviously if the attacker can turn off Secure Boot (or install their own trusted keys), it doesn't prevent anything. Thus you either need to require authorization before overwriting firmware settings or prevent disabling Secure Boot altogether (different devices take different options here). "Require authorization" can look like a lot of different things; sometimes it's simply that there's no way to do it from within a running OS (in which case an attacker with physical access may be able - assuming there's no other protections - but malware on the device would not) but usually it implies a setup password or similar.
Secure Boot has a number of uses, but the most legitimate (IMO) ones are for protecting user devices against two classes of attacks: boot-time rootkits (sometimes called "bootkits") and compromised disk encryption boot code. Secure Boot is also used to lock down devices shipped to customers.
Bootkits are straightforward in principle: if you can gain code execution before the legitimate OS even starts, you can completely own the system, undetectably, forever (potentially even if the disk is reformatted, depending on where the bootkit is installed). There are various ways to do this, such as abusing hardware virtualization support to install your own hypervisor and lift the OS into a guest VM that only thinks it's running on bare metal. This is much worse than normal malware, where simply deleting malicious files and at most reinstalling the OS is sufficient to clean the device.
Disk encryption code is a narrower but similarly important target; the disk encryption requires some code that runs before the OS boots (because the OS's installation is itself encrypted), and if the attacker modifies that pre-OS boot code (which can't, itself, be encrypted or you'd have a catch-22) then they can capture your disk decryption key, passwords, etc.
Device lockdown - which applies to everything from consumer devices like smartphones and game consoles to industrial and telecommunication hardware used by corporations or governments - is an attempt to prevent the customer from modifying or repurposing the hardware or extracting secrets from the device (usually in combination with encryption). This is used to implement DRM, anti-cheat protections (e.g. on consoles), firmware encryption (where the customer does not have the key, or any credential to derive it from) where the firmware contains private keys or other secrets, or even just IP that the vendor doesn't want reverse-engineered, and so on.
With those use cases in mind, let's look at what Secure Boot does.
why would [the attacker] need to install a modified bootloader (assuming they are aware that Secure Boot is enabled)? What prevents them from installing a copy (maybe stripped down) of the legit OS bootloader and kernel, signed by the vendor?
Well, why is your vendor signing bootloaders that do what the attacker wants? Unless the attacker stole the vendor's private key, they can't install anything that the vendor didn't sign (or at least, it won't run), and presumably the vendor hasn't signed a bootkit that shims the OS boot process and sends all your credentials and Bitcoin wallet keys to North Korea, or that lets you run pirated games.
As a side note, what form of "stripped down" are you imagining wouldn't count as "modified"?
But as soon as system has started, Secure Boot does not control further course of execution. It's the job of the OS to ensure the secure environment.
Strictly speaking true, but in a sense false. Secure Boot doesn't control further execution, but it does constrain it to only those operations that are allowed by an OS that the signed bootloader allowed. As with many such systems, it's a chain of trust. The hardware prevents installing a compromised firmware, the firmware verifies the bootloader, the bootloader verifies the OS, and the OS verifies whatever runs upon it. Or not, in some cases; maybe you the user run everything as Administrator/root and have turned off/never installed any anti-malware or other software security features, and the OS either doesn't have any software restriction features or you disabled/never installed those either. But you could instead have a mostly-general-purpose OS that nonetheless only allows executing software with a trusted signature (this is what Windows RT was, and is approximately what you get with Windows' "S mode" or if you leave on the MacOS option that prevents running anything that wasn't installed from their Store).
Without Secure Boot, a device owner - or anybody else with access to the device - could install (or boot off removable media) their own OS without those restrictions. Or in the case of disk encryption software, pull an "evil maid" attack, trick the user into entering their decryption credentials into the compromised system, and then steal the data off the disk (this is a case where Secure Boot can protect a system even without constraining post-bootloader code execution). Considering that disk encryption is explicitly for the protection of data when the attacker has physical access, that's pretty significant!
