Ninjadoodle - as the manual notes, the reading is a timer-based estimate. There's a lot of stuff that can throw it off. For example if the CPU throttles down in to a low-power mode to save battery, it will take longer to do the same work. This makes the CPU take longer to process a tick, and since our CPU reading is a timer-based estimate, the timer covers more time, and makes for a higher reading. So you can end up with a high CPU reading even when the device is using say 10% capacity, because it's done something like clocked itself down by 10x to save battery.
This happens a lot, and I've also noticed it in C3's GPU measurements too. If you run a benchmark the measurements will steadily increase towards close to the 100% mark, then suddenly jump way down as the workload gets more intense. The device didn't suddenly have less work to do - it's always been increasing - it probably just jumped up to a higher performance mode to compensate for the workload. We can't access the CPU/GPU usage directly in a browser, so we have to estimate it from timers, and this is one of the drawbacks of timer-based measurement: we really measure "how long did the work take" rather than the more accurate "what proportion of capacity is being used".
I made a quick demo and ran it on an iPad Air 2 with iOS 11. It does start at around 83% CPU. However if you touch the screen a bit, the CPU drops down to ~10%. This is probably because it starts in a low-power mode doing work slowly to save battery, but when you interact with it then iOS boosts the priority of the app, powers up the CPU, which does the work faster, so a shorter time is measured, so the engine's CPU measurement drops down.
So yes, it's normal. It's not really using up all your CPU, it's just saving battery. Since we have to use timer-based measurements, you will only get reliable measurements when driving the device to its highest performance tier.