This point has been discussed at length amongst the dev team and partners.
I’ll just raise a couple of points.
The board support abstraction (“hwdef.dat” and the underlying code) was designed to simplify the process of bringing up new boards, and enables two important things:
- It makes it achievable for community members to run ardupilot on many cheap boards. This was (and still is) important to make ArduPilot accessible to as many people as possible, with the hope that it would reduce the number of people starting out with old APM 8 bit boards. That has largely been successful.
- To enable innovation from manufacturers by reducing sunk development time, and hence speeding time to market. This has also been successful, with Cube Orange, Durandal, CUAV X7/Nora, mRo ControlZero and the new mRo H7 board, Matek F765 and H7, etc all being possible without the need for a “compulsory” pinout/standardised board definition.
A third and important outcome has been, as pointed out by Pete, discovering vulnerabilities in some boards that result in overall more robust code.