I am just a user, the only thing I can do is contribute my own humble list of bugs I know of that are so critical that (a) It's beyond me that they haven't got enough attention yet and (b) I don't even see the point in having new major releases of ubuntu without having them fixed. Which only makes sense if it is joined with lists provided by other users, of course.

May I suggest to PLEASE forget the "bug has the 'confirmed' status" criteria when selecting important bugs to take action on!? 
Now that you mention it, that mostly explains how some tremendously critical bugs have remained unfixed across several major releases (which is really frustrating and disappointing). There are kinds of bugs that shouldn't require any confirmation whatsoever to be looked at, or that should be picked by developers (or anybody with the skills to do that) for the very purpose of checking whether they can reproduce them, and hence confirm them.

Consider crashes. If somebody reports a crash of, e.g., xorg, that should be enough to take that bug report seriously and investigate whether there is enough information in it to take some action. If you're going to wait for someone to confirm that, you're almost certainly going to wait forever. Unless you think users may actually be inventing bugs, or thinking a program has crashed when it hasn't. And a bug report generated by ubuntu-bug should contain enough information to discard that hypothesis.
Xorg is just an example, of course. When something as basic as xorg, ntfs.whatever, network-manager and the like, crashes, even if one single person has reported one single crash, it should be enough to trigger developers' attention to it to do whatever can be done to figure out what caused the crash. The only case when a bug report should be "forgotten" until new information is available, is if some developer has actually checked that there's not enough information to do anything about it. Where  "anything" does not necessarily mean "start working at fixing it" but also "try to figure out what _may_ reproduce it", etc.
The most disastrous crashes of the most vital components of the OS are usually hardly reproducible, so if you wait for confirmation or for a set of steps to reproduce the issue, you're going to leave the most critical bugs unsolved, exactly those that most need to be fixed.
Basically, crashes should be treated as confirmed by default (that would mean e.g. encouraging people to confirm their own bug reports if they are crashes, or even have some bot confirm bugs when they contain the word "crash/crashes").


Another thing that frustrates me beyond telling is when I report some critical bug, then I get an automated response that tells me to test the upstream kernel, and the bug report is put into the "incomplete" status, and then it expires. I never going to test the upstream, period. Does that mean that I shouldn't report the bug? Oh well, then you're never going to discover the bugs that "real users" face (where by "real users" I mean any people outside the cyrcle of those actively developing parts of Ubuntu).
That the particular person who reported a bug cannot or is not willing to do additional testing, is not a reason to have a bug expire. That makes me feel like I'm totally wasting my time when I report bugs. 
The very idea of bugs expiring is fundamentally wrong. A bug should be closed only when there is nothing left to be done about it. That means, when it is either fixed, or found to be a duplicate, or found to be invalid. If it is incomplete, then there IS something to be done about it: complete it. Just like a confirmed bug is considered ready to be picked by anybody capable of fixing it, an incomplete bug should be considered ready to be picked by anybody capable of doing the extra needed debugging/testing/figuring-out work so that it can be confirmed and/or triaged. Having a bug expire because it has been in the "incomplete" status for too long is exactly as wrong as it would be to have a bug expire because it hasn't been fixed for too long.