Because you are claiming to be providing something that is "smarter" and "more robust". Not actually testing it enough to find the common case where it doesn't work gives the lie to that claim. It indicates if anything a lack of smartness, and is not robust. (Even Thomas Dickey's Stack Exchange answer on the subject, which is better than what you've given here, isn't robust, as M. Dickey didn't describe how to robustly parse a CPR sequence.)
When people talk about "ANSI sequences" and "ANSI conformant", they also indicate that likely their knowledge comes from old wives' tales and samizdat. The actual existing standards are ECMA-35 and ECMA-48, and the "E" in "ECMA" does not stand for "ANSI". The world of terminals is alas full of people who've worked off informal "escape code lists", or the Appendix for ANSI.SYS in the back of the Microsoft manual for MS-DOS, and don't actually understand in the first place what it is to be standards conformant.
For starters, it is ECMA-48 in both directions, and your code has to be standards conformant, which that absurdly fragile string matching is not. Would you have your own "it's not conformant, it can be disregarded" applied to you? Because it very much does.
In truth, (partly as a result of people working from samizdat and old wives' tales) most terminals and terminal emulators are like your code, not conformant, and by your metric everything should be "casually disregarded", leaving nothing at all; which is hardly a sensible position.
> When people talk about "ANSI sequences" and "ANSI conformant", they also indicate that likely their knowledge comes from old wives' tales and samizdat.
Or maybe some of them are actually referring to ANSI X3.64.
> Not actually testing it enough to find the common case where it doesn't work gives the lie to that claim.
I happen to maintain code that outputs VT100 sequences to control the screen; it's tested on GNU/Linuxes (various emulators), Cygwin, Solaris, MacOS, FreeBSD. Plus remote terminals like PuTTY, various Android SSH clients (ConnectBot, JuiceSSH, ...). So from that and other past work I'm confident that the escape sequence (which can be found in the DEC VT100 manual) works fine in more places than I care to support.
(If the only piece of code in this area I had ever written were the above script, then of course I wouldn't be.)
The script itself isn't portable; it uses nonportable features of stty, and Bash extensions of read.
The parsing of the terminal's response is probably adequate for the intended use, and was labeled clearly as "proof of concept". It won't handle serial line noise. (Actually, nothing will do that under all conditions anyway. Even if parity is enforced, the response can be damaged in such a way that it has valid syntax, but wrong digits giving incorrect coordinates.) Virtual terminals transmit the response reliably.
If you can think of a way that a malicious terminal emulator could target and exploit the flimsy parsing, do share.
I made up my mind some fifteen years ago that if a terminal isn't ANSI conforming, it can be casually disregarded as something unsupported.
It's like testing that web pages work with Mosaic from 1993.