One thing that I learned about reverse engineering is that you can often get very far by just recognizing/guessing what formats and libraries were used by original authors. The article seems to at least partialy confirm this view.
On vocational school we could elect to do long term project instead of practical graduation exam. In my case this involved reverse engineering management protovol used by Merlin Legend PBX in order to port its DOS-based configuration utility (which was in fact emulator of MLX-20L operator phone) to something more modern (and multi-user). One of first things we did was running the binary through strings and ndisasm (I probably still have the hackedup tool to convert MZ EXE to pseudo-COM that could then be read by ndisasm, which was motivated by fact that for various reasons we could not use IDA). What we found out was that it used some weird Unix on DOS emulation layer from AT&T which included Unix-style ncurses and terminal emulation layer.
We tried both to analyze the binary and sniff the communication. At first we thought that disassembling the code would be faster as we had only limited access to the PBX itself and were somehow afraid of bricking the thing. Oneday I just gave up and spent few hours hacking up a way to actually look at the UART data (there were two issues with that: the PBX was somewhat picky about accepted RS232 levels and then slight logistical issue of having preferrably a laptop with two serial ports in early 00's). After we had this ugly mess of wires with four DE9 connectors and active RS232 buffer (powered from adjustable bench supply, needless to say that our advisor was not too thrilled that we decided to connect this thing between somewhat irreplacable PC and still considerably expensive PBX) we found out quite quickly that the actual configuration protocol consisted of XModem for backup/restore, straight ANSI terminal emulation for initial session establishment (and in theory for weird "use PBX as outgoing modem" feature), essentially binary block oriented terminal protocol (think contents of PC text mode framebuffer with one attribute byte for not every character, but block of 8, always sent as whole line) wrapped in weird HDLC subset for the actual interactive configuration and weird handshake reminiscent of OBDII serial protocol to switch between these modes (which probably took the majority of time to reverse engineer).
Interesting aside is that the above mentioned binary block protocol was also used for the UI of almost-ISDN phones that went with the PBX in question. We had access to ISDN protocol analyzer which worked perfectly for normal call flows, but reliably crashed (and not with any kind of meaningful error message, it just overwrote half of its display with random pixels, started ignoring its keypad or otherwise started behaving weirdly in somewhat random manner) any time we did anything more complex. Somehow I think that finding signal that reliably crashes firmware on test equipment which is explicitly designed to debug problems on such interface is achievement in itself :)