It is difficult to tell because we cannot see the full implementation.
Enumerators are handy when you have multiple conditions which are mutually exclusive - if one is true, the rest can’t be. So if you have multiple booleans for drawing modes while only one can be active at a time, you might as well have that as a boolean.
You should worry more about code cleanliness when the functionality or the data is accessed from multiple classes. If the code resides inside a single blueprint and is not accessed by others, don’t worry about it too much. If it becomes the anchorpoint of your project and your other classes directly rely on the data being in a certain way, then you should think about it more.
In general I’d recommend getting on the C++ side once you get a better feel of how blueprints work, as you can program funtionality in C++ that you can wrap into blueprint nodes.
There are ways to make blueprints neater with functions and separate graphs but personally I’ve found writing the functionality in C++ and calling them with nodes in blueprints to be a far better approach once I’m going for that level of structure.
I would group together bools that exclude each other and swap them out for enums.
Instead of having one massive enum to encompass all possibilities I would have specific functions that could take in bool parameters.
Most of the bools you have also seem like they could be local scope parameters in a specific function or are just local validation states that don’t need to be globally exposed.