I’m not familiar with NSpanel. Why does it write serial messages to EEPROM? That seems like a really odd solution but I’m not familiar with the software or application so I’m not in a position to critique the setup. Does seem unusual thought.
That‘s not what I meant to say; sorry if I haven‘t been clear. The NSpanel uses a JSON based protocol. Meaning the Nextion screen receives messages like this one {"HMI_ATCDevice":{"ctype":"device","id":"1001383218","outlet":0,"etype":"hot"}} (79 characters; don‘t ask me why it is the way it is; I don‘t know). Each message has an additional header and a CRC checksum at the end. The CRC is (likely) done using Nextions CRC commands. Long story short NSpanel itself has nothing to do with EEPROM. I only used it as a real-world example for a lengthy protocol used with Nextion screens. When I chose the example in my previous post I assumed that custom checksums - possibly with custom protocols - are a frequent reason for looking into string to ascii ordinal conversion. The NSpanel itself may not need such a conversion yet other, similarly long, custom protocols could need it.
The problem I see with the string lookup table is the RAM consumption. […]
Nope, nope, nope. I mean, you could put it in the RAM but you absolutely don‘t need to. Hardcoded strings (as in fvanroies example above) do not consume the „user“ RAM in Nextion. Assuming that one or two of the sys0, sys1, sys2 variables are available (usually yes), you don‘t consume any additional RAM. Believe me, I‘d have included it as disadvantage otherwise because I agree, it would be an important one.
Btw you wouldn‘t need to put the full 256 characters into ram because Nextion doesn‘t support most of the non-printable ones anyway.
As for Nextions poor EEPROM spec, I’ve seen a forum post (you too) that makes it clear that it‘s basically them saying „don‘t use it or don‘t ask for RMA“ (Source. Be warned, there‘re a lot of utterly useless replies in that thread). The chip itself seems to be indeed spec‘ed as 1M writes. Or in other words, they prefer giving their customers 100x (10k = 1M/100) worse specs than risking to provide more support for customers… 
Even if they would get returns; it‘s not hard to replace that one chip (and should even be worth the time compared to discarding the display).
As for your test it doesn‘t reveal anyhing new; or let‘s say, I‘d have been surprised if it had already failed. It is after all known that most EEPROM cells under normal conditions outperform their datasheet specs. I still stick with my point that - depending on your use case - you would need to rely on it to outperform its spec by a factor of 100. I guess many people would - rightfully - be fine with a factor of 10 but 100 seems like pushing it a bit too far IMO - even though some devices may exceed even that.
Since the lookup solution does not consume any RAM I wonder if you still consider it „inferior“. I for myself still tend to stay with my position that it may be an easy and appropriate solution for some cases but it shouldn’t be the default solution for all cases. Or in other words, people should at least estimate if they‘re in the 100k or 100M writes ballpark with their application before (mis)using the EEPROM for overcoming such a stupid language limitation (yes, more than anything else do I think that this topic shouldn‘t even exist).
I do wonder how both compare speedwise. I tend to bet on the EEPROM tbh. Interested in doing some benchmarks?
Regards,
Max