You should be able to do that in a template override. Just create an override for the com_fields -> field JLayout and adjust as needed.
But be aware that having an ID based on an option value can get you duplicate IDs on your page and thus invalid HTML. Maybe better add the value to the class instead.

@AndySDH if Answer by @Bakual solves your Feature Request, please close Issue, thanks.

Thanks for the reply!

You're right about adding it to the class being better than having an ID, yes. It was just to convey the example.

Good point about template overrides, but how would I go about getting the option value in order to add it to the class? I believe the $value variable generates the Text (name) and not the value?

Also, I still believe this could be useful to be implemented as part of the native core, after all, it only makes sense to add a class based on the value to allow individual styling, it doesn't do any harm, just possible good for those who need it. What do you think?

Also, I still believe this could be useful to be implemented as part of the native core, after all, it only makes sense to add a class based on the value to allow individual styling,

I assume this would be an issue with punctuation and non-English characters for class names.

Good point about template overrides, but how would I go about getting the option value in order to add it to the class? I believe the $value variable generates the Text (name) and not the value?

Within the JLayout, $field->rawvalue contains the raw value of the field.

Within the JLayout, $field->rawvalue contains the raw value of the field.
@Bakual That did the trick :)
Thank you!
Think if you want to consider this as a part of a core edit or not, if not feel free to close the issue 👍

After testing this a bit, this should not be added as a render field JLayout, because this won't work if multiple values are displayed.
Note: I of course did an if statement for the field type to make sure to add it only for certain types of fields (for example fields like editor, text or calendar, etc. should be excluded for obvious reasons)

But like I was saying, in case multiple values are selected, the rawvalue class will show up as "Array", of course, and you won't have a class for each individual value as desired.

So I think this should instead be added where the individual value gets generated, that means that we should have to end up with something like this:

<span class="field-value">
   <span class="green-option">Green option</span>
 </span>

And in case of multiple values:

<span class="field-value">
    <span class="green-option">Green option</span>, 
    <span class="red-option">Red option</span>, 
    <span class="blue-option">Blue option</span>
</span>

But I didn't find where to do this yet.

The actual field value is rendered by the respective formfield plugin. In case of the list one it is here: https://github.com/joomla/joomla-cms/blob/staging/plugins/fields/list/tmpl/list.php#L22-L28
That layout can be overriden as well.

Personally I don't think this should be done in core. It's a quite specific use case which can be solved with overrides and as you pointed out yourself it isn't as easy as it seems and could break in several ways.

I'm closing this issue due to this reasons.

@Bakual Hey man, sure, understandable.
Thank you very much for pointing me in the right direction, I was indeed able to override those templates, it's a blessing that those plugin templates happen to have been made override-able, since to my knowledge almost no other plugin is. So, thankfully they are, I accomplished exactly what I wanted now.

Take a look:

(building a game database)

PS: I also had to remove htmlentities from the echo, otherwise the html tags wouldn't work in the override.

Thanks again