BOOT1 can certainly be a solder-jumper, but BOOT0 would be "inconvenient" to have as a solder-jumper.
Basically, the work-flow is like this:
1. Screw up the firmware, and notice that you can't attach to flash corrected firmware
2. Hold BOOT0 high while applying power or resetting, and flash correct firmware
3. Let BOOT0 go low again
I.e, you only need it high for a few seconds. Soldering would be inconvenient. How about a test-point where you can apply VDD ?
While we use the LM317 a lot, it's not a perfect LDO for this use-case. We use it because it can do 1.5A (with cooling), and it's adjustable from 1.25V -> ~35V. Neither of which we need here.
Without researching prices, maybe something like the MCP1700-33 would work here?
( You can keep the one you're currently using. I'm just wondering if there's any cost-benefits to switching )
I don't have any recommendations for an inductor on the SD card. Never used one myself, because I usually use name-brand SD-cards (which I assume are well-behaved).
As for exposing nRST. I guess if the problem occurs, we could get around it with a BOOT0+reset-button manouvre. Could we add a solderable test-point, so we could solder in a wire if it becomes a problem?
A voltage reference a little bit away from the MCU, passing through a connector? Doesn't seem like it would be incredibly accurate. However..
You could/should add a little voltage-divider from VBAT into one of the ADC inputs, so we can measure the battery voltage at least. Maybe a little FET as well, so we can disconnect the divider (as it will leak otherwise).
USB wise, I think we/you would need at least a VBUS_Detect pin, if for nothing else, power-management (so we know when we can power-down the USB peripheral in the STM32). A voltage-divider (15K/22K split) from VBUS to a GPIO should do fine for that.