This likely comes down to a design choice. Given the system you described, it sounds like you are using pretty small render textures, maybe 256x256 or 512x512 at the worst, and you currently expect 6-10 textures at a time (lets say 20 in case you need some for the future). Personally I would consider one of the following options:
1.) Creating and destroying render textures as needed is technically okay (you may run into a small frame drops depending on resolution and number for render textures). So you can probably keep going as is so long as you are not using HDRP (cameras get expensive fast in HDRP).
2.) Use render texture pools to avoid the frame drop in creating up to 20 render textures. This doesn't solve the HDRP camera issue but should be okay in URP so long as you don't get too crazy with additional cameras (think I tested up to 50 or with a 1080 on Windows). There should be many examples of how to do object pooling online, combine this with a singleton pattern so you can grab them from anywhere in your game as needed.
3.) Create one dedicated camera that renders only game objects on the portraits layer and have a script that moves special character portrait prefabs into position so you can render out a single render texture Atlas of all portraits needed at the moment. This should eliminate all costs associated with creating new render textures, new cameras, and most camera render time (you still need one). This is the approach I normally take for HDRP projects when I need to do stuff like rendering text in Visual Effect graphs. It's tricky to setup but should work in most cases. Just make sure your render texture is the size of "portraitResolution.X x textureAtlasColumnCount, portraintResolution.Y x textureAtlasRowCount". So for 20 rendertextures at 256x256 that would be roughly 1280x1024 or 2560x2048 at 512x512 with 5 images per row and 4 rows. To use these images you can adjust the UV offset on any materials that take the texture atlas as a texture.