There isn’t an automatic way to fix this sort of thing because the device tree has no idea of which pins are “critical” and which ones are “optional” (such as the LEDs). The proper way to fix it is just what you have done: modify either the base device tree that is loaded into memory by the bootloader or create a custom device tree overlay that maps just the pins that you need. If you are developing a custom embedded device with known, fixed hardware, you would modify the primary device tree. If you’ll be swapping around cape hardware a lot and prototyping, then the overlay is the way to go.
One thing that you might consider, since it is a super lower-cost approach, is to use a USB audio dongle. They are quite small when the casing is removed:
This one cost me about $4 through Amazon. It is small enough that I can fit it between the LCD cape and the BBB. You’ll have to plug it into the USB host port, of course, but I found a small USB hub for under $10 that allows me to keep the LCD cape footprint. I just soldered the audio dongle directly to one of the USB ports:
… and then I placed both the hub and dongle under the cape. I am using the LCD3 cape, though, which only uses about half of the P8 connector, so I was able to fit the audio dongle on top of the P8 without having it stick out from under the cape:
http://i.imgur.com/JHmStiF.jpg (Both speaker out and mic in are available)
You could get away with fitting this same dongle under the LCD4 cape if you unsoldered the male USB connector on the dongle to reduce its size.
The slight tilt to the LCD3 cape comes from the FTDI cable being plugged in, not the hub and dongle that I’ve crammed in under the cape. The host port on the end of the hub is still available for USB devices. In addition, using a nano form factor USB wifi is possible by plugging it into one of the side host ports on the USB hub (which leaves that one exposed host USB port next to the BBB’s host port). For the best signal strength, though, you should use the host port that is exposed at the edge of the BBB.
I have noticed that the USB audio has little skips in it and the occasional buffer underrun if something else is plugged into the hub and CPU usage exceeds 90% or so. My theory is that this is due to PIO being used for USB, rather than DMA. Changing the size of the audio buffer hasn’t had much impact on this. This experimentation is all part of my work to see just how portable I can make the BeagleSNES system: