I thought of many alternatives: create global variable,
This implies a fundamental misunderstanding of how PHP works. Global variables don’t persist across requests, nothing persists from the PHP side unless it’s stored in a file or database, as WP is loaded from scratch on every request. There is no persistant process like a Node web application.
create a custom REST endpoint and fetch directly, etc.
This is what getEntityRecord does behind the scenes, it’s just a helper that benefits from integration with the data store
So my question is, is this an appropriate usage of addEntities and getEntityRecord or am I doing something uncouth? Has anyone else used this method before? Because this approach really opens up a ton of doors to efficiently retrieving external data in the Block Editor.
getEntityRecord? Sure! addEntities? Not so much. There’s a reason settings are only available to admins, it’s sensitive data. By routing them through a custom endpoint you’ve allowed un-secure setting manipulation to happen.
There is an extremely high chance that if we were to learn the reasons for this that the very premise that requires what you’re asking about is not necessary.
Blocks shouldn’t need to know the values of options, and blocks that need to know this when rendered should be rendered in PHP. After all if you save the content, then the option changes, WP can’t go back and update all the posts automatically if you were working with JS to save them.