Incoming code-review. Take it as you want, just going to point some stuff out.
Extensions.cs -> CanInterrupt: Use the built-in API that HB provides. (CanInterruptSpellCast I believe is the API. If not, its something very close.) This will allow you to be patch-proof in the future, and also use HBs optimized internal code.
FlagActions.cs -> FlagAssitance: When you look for the GO's, check distance first. Number comparisons (and math) are faster than string comparisons. Especially when considering Model is read from memory each access. Filtering out far-away GOs first will result in faster lookup times. (On the same lines, OrderBy(u=> u.DistanceSqr). DistanceSqr takes less CPU cycles than Distance, since it doesn't need to run Math.Sqrt on the value before returning.)
In the same function, move the "moveTo" declaration inside the if scope. If the condition fails, you don't need it anyway, so why bother calculating it before you'll actually use it?
Refreshments.cs -> Same as above for RefreshmentTable/Soulwell. Also keep in mind, both of those will only ever be run *once*. (You have them in a static variable, which is not reloaded, ever.) I'd suggest updating them every so often. (If you do, and I missed it, ignore this)
Targeting.cs -> TargetExists: Wrap this in a FrameLock. You're doing a loop of IsInLineOfSight, which is an injection per call. This will greatly increase performance.
Targeting.cs -> EnemyDemolisher: Put the "orderby" statement just before the final select. This way, you're not causing it to order by units that you don't need. Also, change the "where" statements, to simply && checks. Each "where" causes another loop of the entire list. Using a chained "&&" causes 1 big check per loop, instead of 5+. (A common pitfall in LINQ queries)
The same applies to the rest of the functions in the Targeting file.