Small teams shouldn't split like this IMHO. It's better/smarter/faster IMHO to do "all hands on deck" to get things done.
For prioritization, use a triage queue because it aims the whole team at the most valuable work. This needs to be the mission-critical MVP & PMF work, rather than what the article describes as "event driven" customer requests i.e. interruptions.
In a similar boat (small team, have to balance new stuff, maintenance, customer requests, bugs, etc).
We ended up with a system where we break work up into things that take about a day. If someone thinks something is going to take a long time then we try to break it down until some part of it can be done in about a day. So we kinda side-step the problem of having people able to focus on something for weeks by not letting anything take weeks. The same person will probably end up working on the smaller tasks, but they can more easily jump between things as priorities change, and pretty often after doing a few of the smaller tasks either more of us can jump in or we realize we don't actually need to do the rest of it.
It also helps keep PRs reasonably sized (if you do PRs).
A triage queue can include how/when to do triage. As a specific example, set 60 minutes each Friday to sift through bug reports together. Small teams with good customers can reply honestly with "Thank you for your bug report. We're tracking it now at $URL. We expect to look at it after we've shipped $FEATURE. If we've misunderstood the urgency or severity please call us directly at $PHONE."
For prioritization, use a triage queue because it aims the whole team at the most valuable work. This needs to be the mission-critical MVP & PMF work, rather than what the article describes as "event driven" customer requests i.e. interruptions.