My test for this kind of thing is this: suppose you need to make a high speed implementation in Verilog for an FPGA or ASIC. By high speed, I mean that you need to process multiple characters per cycle (say a 64-bit word at a time)- if you have to make a decision on a byte-by-byte basis, it's too slow. This is a very possible scenario if the protocol catches on: for example, I made HDLC byte stuffing for PPP framing, 4 characters at a time (at least better than bit stuffing).
The CRLF encoding is not so bad in this case: read 8 characters, in parallel detect CR. If there is no CR in your word, just append the data to the buffer. When you do have a CR, it's a big pain: you need to save the last word with byte masks, then shift any remaining for the next input (and the entire next string is shifted by this left-over balance). You could try to make all strings a multiple of 8 in length to avoid this, but this adds overhead to the message so is inefficient- the hardware will just have to do it.
OK, so now in your new format the hardware has to parse a variable length decimal number and convert it to binary (ideally in parallel), very fun! You could make the conversion byte at a time, but it's slow. You need to implement overflow detection.
At the very least use hex instead of decimal. Even in software you may need overflow detection. This is easy in hex, not so much in decimal. Better is to require the number to be a multiple of four or eight digits, even though this is a waste of bandwidth.