I have, in fact, had incorrect dosing happen, including the worst-case scenario of an incorrect large bolus at night. (That happened because of a bug on the git head branch, not a release version, which is much riskier. As a developer of the system that's a risk I knowingly accept.)
And that's not actually that bad. The important thing to realize is that the point of comparison isn't a zero error rate, it's the error rate a human would make. The worst-case scenario is quite well understood: excess insulin, up to a configured dosage limit. And that's an error which humans definitely make--it's not even a rare mistake, it's a mistake that a human doing everything manually will make multiple times per year, every year.
Is the configuration software controlled? IE, if you had a bug in your configuration or in your microcontroller, could that bug lead to exceeding the configured dosage limit? Or is there a hard limiter (fixed amount of insulin, a physical limit switch, etc) that prevents that.
The chances are this is unlikely, for legal reasons: Medtronic creates regulated medical devices. I wonder whether it would be possible to add something along the lines of "push this (software/hardware) button to allow non-regulated 3rd-party hardware and software to begin controlling your medical device, but doing so will bind you to <insert waiver here>" and get such functionality to pass FDA approval. I somehow suspect not, although I would be very happy to hear otherwise.
As things stand now, though, it sounds like (as the article suggests, with the picture of a "hacked pump") people are still relying on methods and techniques that it sounds like anyone can use. So yes, unfortunately everyone's in a situation where any adversary within Bluetooth range could probably take the device over, and (depending on the severity of the vulnerability being used) perhaps modify the pump itself to pump too much or too little regardless of inputs, or similar.
Quite an uncomfortable situation from a security perspective. :/
Every type 1 diabetic has some parameters that they use to determine how much insulin they need: an insulin to carb ratio, an insulin sensitivity factor, and a basal rate (or several basal rates for different times of day). The way these parameters are traditionally managed is that your devices collect data about your carbohydrate intake and glucose at various times of day, and every 3 or 6 months you bring those devices to an endocrinologist's office where they print them out, a doctor looks at the printouts, and the doctor suggests tweaks to the parameters. This process works very poorly, first of all because 3-6 months is too infrequent, and second because calculating the correct parameter tweak requires a whole lot of math, not just looking at a printout.
The way it works in OpenAPS is that a program runs nightly, looks at historical data, figures out the correct parameter tweak, and applies it for the next day. This works much better. Much better long term health, much better quality of life, much lower short-term risk of death. But if someone dies, there's no doctor to pin it on. So device makers don't include that feature.
(This is the clearest example, but there are others as well. There are also things like where alert thresholds are set; too few alerts and you're at risk of failing to alert the user to something important, too many alerts and you cause alert fatigue and impact quality of life.)