I remember the YouTube feather opt-in being spread by word of mouth at the time by folk in the tech community on fast connections. People really care about this stuff and the only reliable way to know is by engaging them directly.
By the sounds of it, though, it was a net loss for Google, which is why the page is still so big. Much of the code might have been irrelevant (even harmful) for the end user, but was necessary for Google's business model.
So a side-learning ignored by the article is that there are more types of stakeholder than just the end users, especially in applications that are free (as in beer) at the point of use. And more stakeholders means more complex solutions. And more complex solutions typically mean more code and bigger pages.
It depends a lot on the content. The example I’m about to show comes to about 114kbps (14.25KB/s).
You can inspect this sort of thing with tools like yt-dlp (the superior fork of the probably-better-known youtube-dl). Here’s one example from a well-known music video:
$ yt-dlp -F 'https://www.youtube.com/watch?v=dQw4w9WgXcQ'
[youtube] dQw4w9WgXcQ: Downloading webpage
[youtube] dQw4w9WgXcQ: Downloading android player API JSON
[info] Available formats for dQw4w9WgXcQ:
ID EXT RESOLUTION FPS │ FILESIZE TBR PROTO │ VCODEC VBR ACODEC ABR ASR MORE INFO
────────────────────────────────────────────────────────────────────────────────────────────────────────────
sb2 mhtml 48x27 0 │ mhtml │ images storyboard
sb1 mhtml 80x45 1 │ mhtml │ images storyboard
sb0 mhtml 160x90 1 │ mhtml │ images storyboard
139 m4a audio only │ 1.23MiB 49k https │ audio only mp4a.40.5 49k 22k low, m4a_dash
249 webm audio only │ 1.18MiB 46k https │ audio only opus 46k 48k low, webm_dash
250 webm audio only │ 1.55MiB 61k https │ audio only opus 61k 48k low, webm_dash
140 m4a audio only │ 3.27MiB 130k https │ audio only mp4a.40.2 130k 44k medium, m4a_dash
251 webm audio only │ 3.28MiB 130k https │ audio only opus 130k 48k medium, webm_dash
17 3gp 176x144 6 │ 1.97MiB 78k https │ mp4v.20.3 78k mp4a.40.2 0k 22k 144p
394 mp4 256x144 25 │ 1.71MiB 68k https │ av01.0.00M.08 68k video only 144p, mp4_dash
160 mp4 256x144 25 │ 1.82MiB 72k https │ avc1.4d400c 72k video only 144p, mp4_dash
278 webm 256x144 25 │ 2.27MiB 90k https │ vp9 90k video only 144p, webm_dash
395 mp4 426x240 25 │ 3.37MiB 134k https │ av01.0.00M.08 134k video only 240p, mp4_dash
133 mp4 426x240 25 │ 2.96MiB 117k https │ avc1.4d4015 117k video only 240p, mp4_dash
242 webm 426x240 25 │ 4.02MiB 159k https │ vp9 159k video only 240p, webm_dash
396 mp4 640x360 25 │ 6.57MiB 260k https │ av01.0.01M.08 260k video only 360p, mp4_dash
134 mp4 640x360 25 │ 5.55MiB 220k https │ avc1.4d401e 220k video only 360p, mp4_dash
18 mp4 640x360 25 │ 15.04MiB 595k https │ avc1.42001E 595k mp4a.40.2 0k 48k 360p
243 webm 640x360 25 │ 6.93MiB 274k https │ vp9 274k video only 360p, webm_dash
397 mp4 854x480 25 │ 11.45MiB 453k https │ av01.0.04M.08 453k video only 480p, mp4_dash
135 mp4 854x480 25 │ 8.52MiB 337k https │ avc1.4d401e 337k video only 480p, mp4_dash
244 webm 854x480 25 │ 10.04MiB 397k https │ vp9 397k video only 480p, webm_dash
22 mp4 1280x720 25 │ ~66.22MiB 2559k https │ avc1.64001F 2559k mp4a.40.2 0k 44k 720p
398 mp4 1280x720 25 │ 23.71MiB 938k https │ av01.0.05M.08 938k video only 720p, mp4_dash
136 mp4 1280x720 25 │ 16.56MiB 655k https │ avc1.4d401f 655k video only 720p, mp4_dash
247 webm 1280x720 25 │ 16.97MiB 671k https │ vp9 671k video only 720p, webm_dash
399 mp4 1920x1080 25 │ 45.16MiB 1786k https │ av01.0.08M.08 1786k video only 1080p, mp4_dash
137 mp4 1920x1080 25 │ 89.66MiB 3547k https │ avc1.640028 3547k video only 1080p, mp4_dash
(The source article speaks of 100KB taking 2 minutes, which corresponds to 6.7kbps, which is extraordinarily slow. Well, at that rate it would take you an hour to load the 3MB of the video in this example, though experience suggests that at those speeds other stuff is extremely likely to clog things up further. But then, maybe that clogging is already taken into account.)