Why isn't the ESP32 used for quadcopter flight control?
Your general question is of course too broad to be a fit here, but the specific question of selecting a processor for a quadcopter can be addressed.

Mostly what is missing is awareness of the actual task.

A little historical perspective would show that this was a problem routinely solved with small 8-bit flash-based MCU's like the STM8 and ATmega series.  Talking to a packetized 2.4 GHz radio, reading a MEMS sensor or two, damping roll, and optionally restoring "level" are really not computationally demanding or high memory resource tasks - even if you add extras like a flip-button.

However, fairly quickly, most commercial toys and open source projects have moved on from 8 bit processors to 32 bit ones, typically ARM Cortex M0 or M3 devices.  This to some degree reflects an industry trend overall - these parts are very inexpensive, and today you often pay primarily for the flash and RAM sizes, not the capability of the core.  Most budget toys are flying with STM32's or work-alike GigaDevices parts, a few have Nuvoton, and then there's a whole category using combined Radio/MCU parts undocumented in the west.

In terms of considering the ESP32, this is probably not what you want, for several reasons:


It is not a unified flash-based MCU, rather it (usually) requires an external SPI flash, which is one more part you have to source, route, and one more failure point
Neither WiFi nor BLE is really suitable for remote-commanded flight.  For this you want something that at the air level does not involve sessions and does not involve retries.  Lost packets are a certainty, but the proper cure is to just follow them with good up-to-date packets, not to keep trying to send ones containing increasingly stale commands.  While there are some options to run these radios in more raw modes, that's not an area that has received much exploration.
The documentation and available knowledge still has many unexplored dark corners - especially but not only with regard to the radios.
You will be pretty much on your own software wise.  Even if your goal is to write a fully custom firmware, being able to quickly port an existing one to your pin mapping lets you validate the circuitry and airframe so that your software work can be just about algorithms and software, rather than facing all the problems at once.


Some features that are typically desired in an MCU are:


Fully self contained flash and RAM requiring minimal support components. Having multiple memory sizes in the same package lets you have high memory development units with extra output, and cheaper low memory production ones.
Hardware I2C and SPI for talking to sensors and radio (and a UART for debug output is very handy)
At least four hardware PWM channels for directly driving brushed motor FETs or providing legacy style servo signals to external speed controllers.  (Some modern ESC's use complex signaling which would benefit from DMA-backed interfaces, identifying the proper hardware channels for those is an art itself, but a beginner shouldn't be messing with aircraft large and therefore hazardous enough to use those)
Ability to operate at 2.8 volts or less, to allow selecting an LDO voltage headroom when operating from a single cell which may substantially dip under load when flying aggressively late in the discharge cycle.


Before doing original work in this field, you'd be wise to pick up one of the current generation of 15-18 gram $15-20 ducted prop aircraft running on an STM32F0 with labelled SWD port, and an available open source alternative firmware.  That gives you plenty of opportunity to learn without the lengthy effort of designing and assembling a tiny board and airframe - and you can of course swap out parts, putting the stock controller on a custom airframe or a custom PCB on the stock airframe.  It's also rather helpful to have something tiny enough that you can unclip the SWD leads from and fly right off the lab bench, without having to invest all the time in hauling everything outdoors.