They can totally look at it, but if they copy it into Windows Terminal, they need to relicense Windows Terminal under the GPL. That would be a great outcome for everyone. Microsoft is already shipping Linux under the GPL2 as WSL2 so this shouldn't be unthinkable.
Also, though, it does not require 25+ years of game development experience to figure out that you can write a non-laggy terminal emulator, which should be obvious because people have been building non-laggy terminal emulators since at least 01974 and people routinely watch 1080p videos at 60 fps on modern laptops and even modern hand computers.
We had terminal emulators with acceptable, even snappy, performance on X-Windows when I started using it in 01993. In 01994 I would commonly use an IRIS Indigo, which had a 150 MHz R4400, which was not superscalar, so it was maybe capable of 150 MIPS, or 300 MIPS if you count floating-point too. I preferred using it instead of the X terminals because it was faster. I'm typing this on an obsolete laptop whose CPU averages about 100 times faster than that. It's immediately obvious to the most casual observer that there is no excuse for software on this laptop to flub UI tasks the Indigo handled with ease.
The VT50 https://en.wikipedia.org/wiki/VT50 was released in 01974, and its microprogram emulated a Teletype with added features. (See my comment at https://news.ycombinator.com/item?id=32547666.) A service manual for the 01975 version, the VT52, is at https://news.ycombinator.com/item?id=32547666. It had 60 frames per second (in the US), 240 scan lines per frame, 80 characters per scan line (at 15.36 kHz), and I think 8 pixels per character (in each scan line), one of which was always blank. So its output shift register ("VSR") operated at 9.8 MHz, or actually a little bit faster because of the 10-μs HBI, during which it checked the keyboard. Its microprogram, which had to load the appropriate 7 bits into the VSR 80 times per scan line (as well as processing escape sequences and printable characters during, I think, the VBI), had a 1.3 μs instruction cycle time (770 MHz), divided into 18 72-ns clock cycles (13.824 MHz) during which it did different things.
So I think that in most 72-ns clock cycles about a couple of dozen flip-flops would change state.
This laptop typically executes about 2400 CPU instructions in every 72-ns tick of the VT52's clock, 600 per core. You could compile an RTL-level logic simulation of the VT52 into C and compile it with a C compiler, and it would run faster than the original VT52.
But that would be sort of stupid because you have a framebuffer and a GPU with texture-mapping units; your CPU doesn't actually have to generate pixels one at a time to keep the screen refreshed because you have hardware to do that for you. A 1920×1080 video at 60 frames per second is displaying 124 million new pixels per second, which it has to get by decoding H.264 or H.265 or something. That's a bit over 1.5 million VT52 characters per second. But when you're displaying characters on a terminal that isn't very useful because people can only read about 30 characters per second; even updating a full-page 80×66 display at 60 frames per second is only 0.3 million characters per second.
In most cases the computation required to process a character is to verify that it's a printable plain ASCII character, update the screen image, and update the cursor position. Updating the screen image might involve blitting some texture data or, as in Muratori's refterm, updating a glyph index that gets consulted by a shader to figure out what texture data to draw when the time comes to render a frame. We're talking about an amount of computation that's small compared to a typical C subroutine call and return.