What's acceptable battery usage?

The only real "gate keeper" is the users.  If they think it's using too much battery, you'll hear about it.  A very simple WF will consume less battery than a complex one, and if you use onPartialUpdate, that will consume more, and if you have a background service, that will also consume more.

And recall, different devices have different battery lives.  Some may need to be charged every couple days, while some can go a week or more

Run your WF for a few days and keep an eye the battery level, then download something from the store and do the same and see how they compare.

Is this something that correlates well with optimizing time spent in onUpdate in the profiler?

So far I would say yes. I've tried a lot variations of layers, full size bitmaps, little bitmaps, color palettes, drawing to dc directly, full updates, partial updates, awake and not awake, rearranging code, splitting calcs, combining calcs, and so far I've managed to cut onUpdate time by 2/3. Still not fast enough for partial update but close. I've even added "how much time does the watch spend awake every day" (about an hour not using any apps) and "what percentage does the battery drain every day" (down to under 4% per day) fields to the face to see what improvements are working. Also managed to get the size down about a 1/3 too.

Here's a thread all about onPartialUpdate and talks about the 30ms avg,  The more rows you have in the clip, the higher the battery.

https://forums.garmin.com/developer/connect-iq/f/discussion/5156/1hz-watch-faces---q-a

Note the posts that talk about "watch face diagnostics. In low power mode, the avg over a minute needs to be under 30000 (the top line)Could that be what you called the "gate keeper"?  The power budget number when using onPartialUpdate.

Gate keeper was an oblique reference to the "Garmin approve/deny powers that be" for apps and the like for the IQ store. Following the 1Hz thread, what I've never understood, and never tried to find out, is if the area drawn in the set clip has to be "redrawn" back to the way it was before you can draw something else like a second hand over a tick marks, or if clearing the clip does that so you only have to clear then draw like you do with layers. I also wonder what the speed of a offset bitmap draw would be to a draw of an object like a polygon in the same size clip area?

I don't know about the clip+clear (it's an interesting question), but regarding the offset bitmap (if i understand what that means...) Why would that save time? The reason to do that (and I'm not sure how much that applies in watches, but it might also depend on the tech it uses) would be to prevent flickering when the screen is refreshed when the drawing is only half done. It actually adds time because (best case) the drawing takes the same time (or more) and then it needs to be copied to the real place.

Look at the analog sample in the SDK.  (note - it doesn't work with 4.x devices, and only devices with MIP displays as AMOLED devices don't have onPartialUpdate).  As the second hand moves, it uses a BufferBitmap in the clip region for the background).  If you are in low power mode, and use watch face diagnostics, if you watch that over the span of a minute, you;ll see the impact is lowest when the second hand is at 3 and 9, and highest at 6 and 12, as the clip region uses fewer rows on the display and 3 and 9, and the most at 6 and 12..

Here's the analog sample, in the sim. in low power mode showing watch face diagnostics with a fr935 as the target

it's showing the last time onPartialUpdate was called it took a bit over 14ms, but based on the numver of rows of the display in the clip, it will be between about 8ms and 22ms, and the key is over a full minute, the average needs to be under 30ms