Post History

Regarding string-based common protocol vs binary, there are indisputable reasons why binary is simpler, faster (these days rarely limiting), and arguably less trouble prone up to the level of complexity implied by the OP's scenario. 

However a common scenario is that the data itself has string form, particularly metadata in systems with lots of configuration options. 

Especially when families of devices are created with configuration schema that are analogous yet not interchangeable, this can make _named parameters_ (eg "config.sensor[3].scale.min") nicer to work with than _numbered registers_ which have different mappings across product variations or versions. To be clear this is for in-house software integration and developer use, whereas if there is a customer facing protocol IME remains better off as the equivalent of "read register 3", "write register 5", just from simplicity.

Anyhow, if the scenario is one where you are transmitting string values, there isn't much reason not to go with string commands as well.

Regarding the implementation, I would suggest the bounded strncmp() rather than strcmp(). 

Regarding UART as a physical medium, the case where it can work out is serial-over-USB, where the physical length of raw UART signal is a few centimeters to a galvanically isolated USB interface section (or none at all if built into the MCU). In that scenario, any customer with a computer and generic terminal software can help you troubleshoot over phone/screenchat.

Also a mention to encodings like modbus ASCII, which are binary encoded into two characters per byte, with often fixed line length, and a checksum byte at the end  ... eg ":A2B2FCECC12523D5BF" . Tho this isn't exactly human readable, it remains accessible via terminal without dedicated software.