STM32F091 VBat pin sinking a lot of mA's
I don't see a definite "smoking gun" for your problem so far. Therefore this is some analysis of the partial schematic supplied, which may lead towards more tests which actually produce an answer. However, since this won't fit in (even several) comments, I'm adding it as an "answer":


Just FYI, and not related to your problem, but the 100k pull-ups on I2C1 and I2C2 are very weak, and may be inadequate. Once you get the MCU working and can run some code, check the I2C waveforms for correct rise/fall times. I suspect you will need stronger pull-ups.
One concern I had, was whether a signal voltage was being applied when VDD was off (i.e. with only VBAT active). Based on your updates, that doesn't seem to apply, but I recommend you review the full schematic, to see if that situation is possible.
The localised issue around the VBAT pin (it seems to be localised since, as you said, other parts of the MCU work OK) suggests that VBAT is involved somehow. You mentioned VBAT being supplied from a battery, and later you said it is being supplied from a bench power supply (PSU). The latter is unusual, but I can't point to a reason why that won't work. I would use an oscilloscope to view the voltage on VBAT when you switch on that PSU, watching for overshoot or other similar issues.
Another area to investigate, is the VDD supply. This hasn't been discussed much so far, and it might not seem relevant due to the visible symptom being with VBAT. However VDD will have been used to power the MCU during the attempted programming - and it is after this process, that you say the excessive VBAT current was found.

My thought process is that if VDD actually went briefly negative with respect to VSS during power-off for any reason, then the fact that there is another power source available (VBAT) could lead to unexpected issues in that area. Issues with VDD glitches to separate battery-backed RTC chips are well-known (a reverse-biased Schottky diode across VDD &amp; VSS is the usual solution). I can't "join all the dots" to blame VDD behaviour with the data presented so far, but it's an area I definitely recommend investigating.
In the current version of ST Reference Manual
RM0091: STM32F0x1/STM32F0x2/STM32F0x8 advanced ARM®-based 32-bit MCUs
it says in section 5.1.3 (Battery backup domain) on pages 80 / 81:



tRSTTEMPO is shown in the STM32F091 Datasheet section 6.3.3 (Embedded reset and power control block characteristics) on page 55, as being between 1.5ms to 4.5ms, with a typical value of 2.5ms.

Therefore as I understand the above warning, if VDD rises within that time and VDD > VBAT + 0.6V then current injection to VBAT can occur.

I haven't see the VDD voltage mentioned in this topic yet, to know the result of the above formula. However adding the "low-drop" (e.g. Schottky) diode recommended by ST, seems like sensible mitigation to avoid potential problems caused by this behaviour inside the MCU.
The lack of any pull-up or pull-down resistors (apart from on the two I2C buses mentioned earlier) visible on the partial schematics, would mean that until the MCU is programmed, almost all of the MCU GPIO pins will be floating digital inputs (confirmed in the Reference manual RM0091 section 8.3.1 General-purpose I/O (GPIO) ).

These pins are connected to other parts not shown in the partial schematic, but from the signal names, many are also inputs. This situation (inputs connected to inputs) could lead to undefined voltages on those pins, until code is running on the MCU and pins can be set to outputs where required, or internal pull-up or pull-down resistors can be activated, or until external components pull those inputs to valid logic level voltages. This is discussed here, and in lots of reference literature: Is it really a bad idea to leave an MCU input pin floating?

In general, best practice is to install pull-up or pull-down resistors on signals, to hold them at valid voltage levels while they are not being actively driven. One consequence of floating inputs can be excessive power consumption (due to the input transistors staying in the "threshold region") which is an interesting symptom in the context of this question.
As you saw in my earlier suggestion, I suggested you could buy an STM32 Nucleo with the F091 MCU and modify it to add a separate VBAT supply (by default, VBAT is connected to VDD on that board). I found that someone has already done that on a slightly different Nucleo board, with some photos of the modification which may help you if you decide to go ahead, here: Battery Backup for RTC Clock &amp; Registers on STM32 Nucleos

Notice the zero ohm resistor or link which must be removed in order to disconnect the VBAT pin from VDD, before you connect a battery to the VBAT pin!
Assuming that you do get an ST Nucleo F091 then here are some suggestions. To make it a realistic test, you would first test the Nucleo board "as delivered", and make sure all is OK.

Then disconnect its on-board JTAG programmer (ST-Link), use your own JTAG programmer which you have been using so far, and re-test. Then use your own USB power supply and re-test etc. etc.

Gradually change the Nucleo board, step-by-step, to become more and more like your original board, testing with your "program the MCU using your JTAG programmer" test after each change (since that process seems to be what has damaged the MCUs on your board).


If you "break" the Nucleo board, then it is something you are doing or something you are supplying (e.g. VDD), probably related to a recent change if you are following the process of making step-by-step changes as I suggested.
If you don't break a Nucleo board, even when it is (as close as possible to) the same as your own "problem" boards, then either: The original problem is still something you are doing, but the different design of the Nucleo is mitigating the problem. Or the problem is in your board design, not what you are doing, and you need to look at the remaining differences (e.g. PCB layout, component choices, etc.) between your design and the Nucleo board for possible answers.



I hope that analysis is useful.