The library is clearly not optimal for your usage, it does show that it is a port of Arduino library to STM32 HAL. While it is very general and configurable how the LCD is connected to GPIO pins, there are some downsides like the delay system.
First of all, the LCD could be connected to a CPU with 1 MHz (1 microsecond) bus cycles. Most commands take up to 50 microsecods to finish execution, so it could execute at least 20000 commands per second. The slowest command takes 2 milliseconds. So the bus cycle delays in the code are roughly 2000 times longer than necessary, just because the minimum delay it uses is 1 ms.
The delays are really an issue. In fact, as you can call HAL_delay at any given moment in time, the next systick will happen anywhere between 0 and 1 milliseconds, so these delays can be even too short as the systick might happen after 1 microsecond. Replace with tuned busy loop to get down to microsecond delays accurately.
- Don't use another CPU for this. Better spent energy would be to rewrite suitable LCD driver from scratch.
- Using interrupts might be a solution, depending on what you mean by that. For instance, writing one character per systick interrupt might work. But only after the delays are fixed to have 1 microsecond bus cycles.
- Yes, many solutions. For example, use another LCD driver that suits your usage better. Use the BUSY flag from LCD, to know when it is ready, instead of always waiting long enough time. Also the suggestions in other answers are good.
Also, when choosing which libraries to use, always consider the licence of libraries what they allow you to do and what they prevent you from doing.