httponly cookies are meant to prevent attacks like XSS by preventing access to them from client-side JS. However, they can still be stolen by malware on the device (there's a whole class of them called "cookie stealers"). Generally, they search through the infected machine's filesystem and pull out any cookies they find, or at least cookies that the attacker would be interested in. No client-side JS is required for this, so the httponly attribute doesn't help. There have also some browser extension-based cookie stealers that may work along similar principles. Take a look at this old open source stealer to get a sense of how they work: https://github.com/Alexuiop1337/SoranoStealer/tree/master/So...
Session-Lock and Chrome's DBSC are designed to combat these cookie stealers specifically. The premise is that even if an attacker exfiltrates the token itself, it would not be able to be used because the server would reject it if it is not signed by the correct private key when the network request is made. This private key can (or should) only exist on the legitimate device, not the attacker's machine. There may or may not be ways to extract the private key as well, but in any event, it would be a much more complicated attack.
Session-Lock and Chrome's DBSC are designed to combat these cookie stealers specifically. The premise is that even if an attacker exfiltrates the token itself, it would not be able to be used because the server would reject it if it is not signed by the correct private key when the network request is made. This private key can (or should) only exist on the legitimate device, not the attacker's machine. There may or may not be ways to extract the private key as well, but in any event, it would be a much more complicated attack.