The point of using a command line is not because a VT100 emulator is an ideal way to view data (it's not). It's so we can combine commands, using pipes and redirection. I don't want to learn special new filtering flags. I want to get raw data that I can pipe to grep or cut or any of the other dozens of tools I've been learning and using for the past 25 years.
The point of using a distributed version control system is so I can store it all locally. This new tool defaults to only 30 items, and cannot fetch more than 100. So even if you're willing to put up with the multi-second latency of hitting their servers for every command line operation (it feels like CVS all over again), you still can't say "give me everything and let me grep it". You have no choice but to use the 3 ways they give you to filter (assignee, label, state -- not title, comments, or date).
I've got a 50Mbps network connection, a 500GB SSD, 16GB of memory, and an 8-core CPU, and now instead of putting all that to work running JavaScript to access my bug reports, I'm fetching them as plain text at a maximum of about 5000 bytes at a time. (Net throughput is on par with an Apple II with a 14.4Kbps modem.) Is this an improvement?
I do not understand why GitHub Issues aren't git repos, like most other GitHub collections. Then we wouldn't need a completely new (and slow/complex/limited) tool to read bug reports on the command line. Perlis had this figured out back in 1982: using common tools for disparate data is a killer feature. That's why we're still using the command line in a way that looks nearly identical to how it worked in the 1980's, and a few generations of other interfaces have come and gone since then and failed to displace it.