Planning for defects

Why would you need to allocate time to defects differently than any other work?

It's never the intention to deliver a defect. If a defect is found while the team is working on implementing a selected Product Backlog Item, it should be fixed before that Product Backlog Item is considered done. Most Definitions of Done from teams that I've worked with include testing and resolution of defects.

However, I've also found that there may be cases where delivering earlier with some known issues can give the team valuable feedback. In these cases, the known issues would be Product Backlog Items and ordered among every other Product Backlog Items. Some teams order Product Backlog Items associated with fixing defects ahead of all other work. Other teams consider the value of each Product Backlog Item independently. For defects found after delivery, those can also be considered as Product Backlog Items.

For delivered defects, one consideration could be how long stakeholders can wait for a resolution. Defects that are highly impactful may not be able to wait for selection in a future Sprint Planning session. I consider it good practice to ensure that the team's planned Sprint Goal does not consume all of their forecast capacity. This allows for things like unexpected reductions in team capacity or unplanned work to fit into the Sprint without disrupting the team's ability to achieve their Sprint Goal.

Where I can find in Scrum Guide the information to allocate time to work in defects?

The Scrum Guide says:

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.

...

The Developers are required to conform to the Definition of Done

I'd therefore suggest that the handling of defects is not a matter of time allocation but of a commitment to be met. The Developers have committed to the quality of the Increment and are expected to manage their time accordingly. They may reduce their capacity to handle new work in order to ensure that existing work is defect-free and Done, for example.

You can find it in the section of the Scrum Guide that describes the Product Backlog.  A defect is work that needs to be done in order to improve the product. 

@Thomas asked, why do you need to treat defects differently than any other work?  In fact, if you don't try to distinguish between defects, updating features, adding new features, or any other work then it becomes much easier for the Product Owner to order the Product Backlog in a manner that ensures the Developers are working on the right things.