I believe this largely depends on the source of the bug. In my experience bugs are picked up in one of two ways:
- Bugs in the work which is currently being developed
- A bug which escaped the in initial QA net and has been either found in a regression test, some exploratory testing, or reported by a customer.
If the bugs you're talking about fall into the first category then they should already be covered in the User Story estimate - how long a piece of work will take to complete includes its estimation of complexity.
However, if we're talking about bugs which have been detected outside the current sprint then there are a couple of different ways of doing this. If they're P1 issues then they're likely to interrupt the current sprint and any estimation is most likely an overhead you don't need (and will be to be looked at immediately regardless of whether they're 1SP or 10SPs). However bugs which can be added to the backlog should be treated as any other backlog item (priorised and estimated alongside any other items). It's also worth mentioning that not all issues raised by customers are bugs, some are scripts/data fixes which should be treated in the same way.
Ultimately any bug will take time time out of your sprint, but a low priority bug which will take a long time to fix will have a much lower business value than an urgent User Story. Estimating the effort involved in fixing it makes this a lot clearer.
In short, estimating bugs for active User Stories and P1 support issues gives little value but there are definite advantages of estimating anything which can be scheduled to be fixed in future sprints.