Honestly, my incredibly biased recommendation would be to use my custom Hue Bridge integration, which supports startLevelChange and stopLevelChange on groups:
Then you wouldn't need to use individual bulbs at all (and you'd get the ability to cycle through real Hue scenes like the Hue Dimmer can without emulating this in Hubitat). But I used this app for a long time as you are now before that, using inidividual bulbs with Hubitat's stock integration. The delay between bulbs is inevitable--Hubitat has to send them one by one, then the Hue Bridge likely does the same. I noticed a small "popcorn effect" as you do but nothing too severe.
Hue bulbs do not respond to startLevelChange(up) (to dim up) when off. As it looks like you've figured out, they have to be on for any of the "level change" commands to work. (A setLevel would turn it on, but you can't do that in one fell swoop with my app; you'd need a separate action for that.) I'm not sure about the other half your point 2, the slowness. With four bulbs, you may again notice a "popcorn effect" with all bulbs needing to get the start and then stop commands individually, but beyond that, it should be the same that you see by manually initiating the same commands (startLevelChange with up/down and stopLevelChange) on the device page. The only other thing I can think of is that if your hub is slowed down for any other reason (e.g., runaway custom app or driver or general sluggishness for any reason), this problem would be exacerbated.
But again, I think using a group in CoCoHue would solve most of this. 
For the error: I need to add a check in the off actions for that, but the error is harmless (just means you haven't selected additional "off-only" bulbs, just the regular ones).
