There are a few pitfalls with that approach:
I found when I made a RenderTexture to draw a text on it the context was deactivated and I needed to call setActive with the window or loose a frame of drawing.
I circumvented it with creating a thread every time, but that is also bad because the contexts of threads that ended will never be destroyed before the program ends (for making it safer to use for users). So I would have to create a single longrunning thread with synchronization and io-queues.
It may cost to create the RenderTexture and activate/deactivate of contexts is expensive and it would also contain more state than a regular Texture.
I decided to get the texture, create a fresh texture with the copy constructor, then destroy the RenderTexture, as I will keep a large number in a cache for a longer time than you. But that will fetch an Image from GPU to main memory and then recreate a Texture instead of a direct GPU memory copy.
I'm shortly before ripping this out and using sf::Text directly (maybe with a bit of Shape::scale) to improve quality, as you only save one size when prerendering a texture (and there is no mipmapping so you have to use a medium size not large and hope activating smoothing helps a bit) and if you resize it later it looks a bit worse, though you may not plan to resize it.
Maybe I later profile it and put in the contrived longrunning thread version with a single large RenderTexture and a single Text to avoid that memory problem, and maybe direct GPU-mem texture copy, but thats most likely not worth it as its fast enough without doing all that complicated stuff.
More likely I put in the direct use of Glyphs/Font as I think they have a single texture with letters inside already. I can prepare my own array of Vertex that reference that texture then and save that instead.