Hi,
I was just considering the cost factor, but really, if you want to gather all the low level GLCD commands packed in some macro functions easier to work with at firmware side, in fact this proposal may be a good option, and it is even found at some designs, on what a dedicated board is used to interface to the module.
If you consider using this Atmega based interface board as an OEM module, it brings some design advantage, releasing main core processor to face to a massive protocol handling, thus managing access to GLCD with high level API driver routines.
However, if you are considering to design this board as a commercial product, and not to apply on same design house, could encounter some issues related to development scope. For instance, if this board is applied at some specific area ( e.g. medical ), we need some special characters which could be drawn and updated quickly to the interface board, once is at the same company, differently if purchased as some standard line product.
Another issue concerns to supply chain scope: If you adopt not the original GLCD, but also an interface board, your design will be tied to this customized product, avaliable at only this company.
+++