JFR was initially designed so there could be one Java string pool object per event field. The purpose was to allow a more fine-grained heuristics when deciding which strings to store in the constant pool and which to write down as-is.

Benchmarking didn't show any benefit, so the mechanism wasn't never leveraged, but the implementation was kept in case it would make sense in the future. With the removal of EventHandlers, the bytecode infrastructure for a string pool per field was deleted and we might as well remove SimpleStringIdPool class and use the StringPool class directly.

It's been unnecessary code for five years.

If we want to revisit this later, a new mechanism that doesn't rely on bytecode generation could be added, similar to what exist now for user-defined settings