When looking at the API, you have to take into account limitations the designers had. Specifically, the API is part of the android layer that Google writes and OEM's can customize. It must, however, support any underlying camera HAL and associated hardware. The software for that is typically written by SoC vendors, and therefore the camera2 API needs to work with existing HAL layers without modification.

Camera API's also need to be performant. Specifically, converting the data from one form to another, compressing or decompressing it, adjusting colorspaces, rotating it, or copying it from one memory to another typically isn't possible to do as part of the abstraction.

Simple things like rotating a 240fps video to be the right way up in real-time really aren't doable, which means those details have to be passed on to the application if the camera hardware is mounted the other way up.

That means the API itself needs to get the application to handle those details if it wants to offer performance.

All those possible hardware details which the API can't hide for performance reasons lead to a huge and complex API. If you want a simple API, you're free to build one on top (and some exist), but beware - performance will be atrocious on some hardware.

Excuses, excuses. Meanwhile iOS API for the same thing requires 1/10th the amount of code, is easy to use, and has great documentation.

Except they can modify the hardware and HAL layers... Google cannot.