A bug is not a proxy for priority. As said it is a parameter that helps defining a priority and, in fine, the position in the TODO list. Whether priority is "high", or P1, or whatever is exactly the same. Usually there no need for too many levels because, as you suggest, it mostly boils down to "now", "afterwards", "whenever", and that changes over time (hence Agile ideas).
BTW, I have never seen someone disguising a feature request as a bug. That is totally unrealistic not least because obviously this is continuously scrutinised and someone doing that would be called out and ultimately fired for shear incompetence (or worse) and because features go through a definition process, it's not someone who suddenly dreams one up and sneakily hide it in a bug report to have it implemented without anyone noticing (what?!)
The distinction between severity and priority is important. Severity is assigned by the person who reports a defect. It is a measure of how serious the impact of the defect is, as said. Priority cannot be set at that point, as it is a judgement made later based on further considerations.
Devs really are as I described in teams that have matured and are organised (but maybe not in "messier" startups). A team lead is not a dev, 'lead' implies a managerial aspect.
Lastly, of course you need to keep track of the number of defects (which can be from customers feedback and production metrics) and of their severity. This is basic QA, you have to know if you are effectively doing a good job in order to improve both your internal processes and the quality of your product.
For example, if I start to see too many critical defects on a component/team I know we have a problem there. If I start to see too many critical defects found after the product has shipped I know we have a big problem.
