Guy who wrote this article made a mistake, his keyframe interval is set to 0, which tells his encoder its free to do scene detection... however, he's exploiting the nature of the encoder (the scene never changes, as its a static image) to create extremely large GOPs, but not as big as manually setting it can go.
Twitch, as do other platforms, have recommendations, but they'll ingest pretty much anything you give them. This means, you can send them 15fps or lower with a ridiculously huge keyframe interval of 10 or more (Twitch recommends 2, 1 is a saner choice for low latency usage, 10 is still gives you enough ability to interact with viewers).
I've toyed with code/static optimized streams, and using x264 instead of HW encoding on a Nvidia Turing (currently the best HW encoder), and playing with custom args: -refs 16, -qmin above 10, -keyint_min set to keyframe interval * framerate (allows 1 I frame per GOP, the rest of the GOP could be near-zero bandwidth P frames), and -tune stillimage (which sets lesser known options which sorta helped here). Static views of an IDE would use extremely little bandwidth.
You'd be optimizing for the IDE view part of a stream, not the stream of you, which would be in a corner of the screen.
All the gens of GCN through RDNA1 are on the spectrum of veryfast to fast, Pascal is fast; RDNA2 (due to inclusion in PS5 and XB2) meets Turing's new bar for quality (so no more low quality console streams on Twitch).
So, none of them compare to veryslow. Ampere will probably have a better encoder than Turing, but I think the fair comparison will still be against medium, not slow. The big change, afiact, will be work on h265, h264 for them is pretty much as good as they need.
Thanks!
As I said in my comment, a keyframe interval of 10 is doable. Don't be afraid of trying large values to see what they do.
Keyboard cameras make sense to me if somebody is streaming eg starcraft where they're hitting 300 APM and it's impressive to watch, but I just don't see the appeal of it for coding.