So, you have different approaches here that could work. I believe it's important to understand what these approaches are designed for before making your choice.

OnValidate [bad choice]
It is triggered sporadically when serialized properties are changed or scripts recompile but it doesn't run consistently, making it unsuitable for smooth, frame-dependent operations. This is great to validate user data in the inspector!

OnDrawGizmos [Recommended for quick prototyping, with limitations]
Perfect for frame-dependent updates while the Scene view is active. On the other hand... it stops when the Scene view is not rendering, coupling the behavior with the editor's rendering process. This works great when you want to render operations your scripts are doing (raycasting, positioning, distances, trigger areas, ...). So... on a practical level it could perfectly satisfy your needs but it's not a great choice for a long-term solution right? Please check OnDrawGizmosSelected too.

ExecuteAlways [not the cleanest choice]
This is great for cases where a behavior designed for running constantly during play could/should also run while not playing. Let's say you're setting up a scene to render a Model rotating on the Y axis in loop: it could be useful to see the model rotating even when not playing, maybe while finishing up with the rest of the environment. --> ExecuteAlways

EditorCoroutines [Recommended for long term solutions]
Provides clean, consistent frame updates independent of Scene view rendering. Requires the Editor Coroutines package and to understand that some yield won't work as in standard Coroutines (WaitForSecRealTime) but... since you were using OnValidate [editor only callback method] and tried coroutines, I assume EditorCoroutines are perfect for your case. Oh, you need to download a pkg I believe.

AsyncMethods [ great alternative ]
Per editor frame using async/await... needs a little effort to get used to it if you never had but it could provide a great solution without having to download extra pkgs or forcing "dirty approaches". This approach is very versatile and it isn't really limited to very specific scenarios.