I helped reverse-engineer the Omnipod insulin pump, analyzing firmware from the S08 microcontroller (a descendant of the Motorola 6800). The #Loop team built a closed-loop insulin control system and
@ps2 wrote an article about it: blog.usejournal.com/insulin-โฆ
Reasons why long-lived branches are difficult to work with number 1.
Master moves on, you do not. The rebase gets more and more painful the longer you live.
I think that kind of thing is quite hard to pin down. I tend to use "+1/+0/-0/-1" as a scale, where "+1" is "I like this, it should merge" "+0" is "I think this is okay, if someone else likes it it should merge" "-0" is "this smells bad but I won't block" and "-1" is "Hells no"
Though I don't agree that devs on your own team should get to bypass PRs -- Even in a team of excellent engineers, things get spotted by others which would otherwise get through.
This is one reason why I distinguish "Change review" which is done on PR/MRs and "Code review" which is done on the codebase as a whole in a periodic/incremental manner.