You may find it's better to add more functionality. Reasons include non-blocking functions, shared use (i.e., from many functions, .c files), standardizing interface (could map it to stdout for example), etc.
For example, writing a string to the display could take up whole milliseconds at a time, precious time that might need to be spent polling devices or responding to interrupts. Not that the write function would be interrupt-blocking, but it has to be if you want to get debug output from interrupt sources...
If it's buffered, like stdout, you don't have to worry about where or when data is sent. As long as the buffer is updated atomically (usually by disabling interrupts, so it should be done quickly, too), it can receive data from any source (main or interrupt).
Downside is the buffer can fill up, so you do need to add checks for that. Much better than completely missing a critical operation though.
Last time I did a HD44780 display, I used a buffer with in-band signaling. Think it was that chars 0-7 were taken over for special functions (locate cursor, clear screen, etc.), and the rest are normal, like 8-15 are the programmable ones (CRAM) which are mirrored in that range so there's no loss of functionality, and 32-255 are normal.
Forget what string format I used on that project... it was a while ago. I prefer to avoid ASCIIZ strings, the downside is fixed-length strings have to be passed by two parameters at all times (pointer and length), and the length is limited (whatever fits in a, char, short, whatever).
Of course if you're doing simple sequential stuff, basically doing Arduino stuff, blocking write functions are perfectly fine, too.
Tim