He got his channel back and this is how it happened.
Ok so the session was hijacked, this is interesting.
For those who dont know chrome (and all of its forks including ungoogled-chromium) there is a security mechanism which I assumed was designed to prevent this.
I discovered it when trying to migrate my browser configuration from one windows install to another, in the old days you could simply copy over your profile folder. Job done. But now if you do that when the browser launches in the new install, it will wipe cookies, saved passwords, extension data and some other data, its a new security measure. The configuration is only valid for that specific windows install, it validates against a unique key thats generated on windows installation. The new official way of migrating a configuration is via online synchronisation which I hate. Google have also been taking down extensions to aid with this, specifically one's that can make a backup of your cookies and then import them again on a new browser setup.
However over recent years a bunch of new developer orientated features have been added to chrome and its forks (firefox has had to adopt them as well to stay relevant). These are related to session storage, authentication storage, temporary cache's and so forth. Traditionally we had a temporary internet cache folder, which was controllable by the operator of the browser, you could configure the path, the size and even disable it altogether. This is currently been phased out. Its also been made hidden in modern browsers as developers didnt like users tinkering. Cookies is similar, they can be controlled within the browser, and many extensions control them also for privacy focused users. These are also been phased out. Developers have long not liked that they had to deal with unstable browser environments, what I mean by unstable in that the operator of the browser was able to change to a non default configuration which is a problem for a web developer. The solution to this by google (and this worked in their own interest as well as a advertising company) is to implement a new storage mechanism within the browser, a sort of reset, so communities had to start all over again by learning about it, and this mechanism would not be configurable by the operator at least by simple means. As an example browsers now have something called LocalStorage. Since the browser operator cant reconfigure it, then the web developer knows they can reliably use it, the operator cannot even restrict the storage space it consumes, its all controlled by the developers of the browser and web developers. There is also service workers, a sort of mechanism allowing websites to act like a service in your browser even after you close the tab, and SessionStorage the replacement for cookies. The critics of these features argued they are a security disaster waiting to happen as well as an invasion on privacy.
Since chrome already protects sessions managed via cookies via windows ID, my assumption is either the attacker's mimicked the windows ID (I am not convinced its that easy as I tried to do this when migrating my browser on a windows reinstall and it still got blocked), or they exploited one of the new mechanisms which are likely more exploitable.
I do agree with Linus's concerns over 2FA.