I've used both. With local hosting, the Dashboard/IDE loads faster, and I have no problems with a bunch of devices authorized (not sure if it's still a problem, but I had issues with the public Dashboard with lots of devices, plus it just took a while to load in general). But it doesn't affect piston execution at all: on Hubitat, they are just child apps of the webCoRE app, and all execute locally. The dashboard is just used for editing, and there is no difference when they are run.
Which brings us to...:
It sounds like @putnamjwp was talking about Hubitat having to recompile the "main" webCoRE app after the hub is rebooted--Groovy is an interpreted language but is ultimately compiled to Java bytecode, and I'm not familiar with the inner workings of Hubitat to know when does that (at runtime, or as much as it can at boot for all installed apps?). But I don't think he meant webCoRE pistons being "compiled"--they are (child) apps, but they themselves have to be interpreted through the parent webCoRE app/runtime.
You do have a neat idea, though--it would be nice to have the ability to convert a piston to "native" Groovy to skip one layer of interpretation and make it faster, an idea Bruce also mentioned above. But I imagine the resulting Groovy would border on unreadable, nice as it may be to have a starting point for converting pistons to native apps (not that it's much harder except the interpreted nature of Groovy and the lack of useful tools like breakpoints, inspectors, or an easy way to unit test make it much harder than writing a webCoRE piston that won't let you write invalid syntax in the first place).
To go back to the first question: webCoRE pistons are locally executed on Hubitat, but generally (just slightly) slower than "native" apps due to the above. In any case, where the Dashboard is hosted won't affect this.