Should we provide story points to defects in Agile Scrum?

What would you say the implications are regarding transparency over the work that remains to be Done?

What value would estimation - regardless of if it's done in story points or some other unit - provide for the team or for key stakeholders? If estimation would provide value for helping the team understand the work that they are being asked to do, plan or monitor the progress of that work, or carry out some other kind of activity, then the team should consider estimation and various techniques for estimation. However, if there isn't a direct connection to value, then I'd consider the lean principle of eliminating waste or the agile principle of maximizing the amount of work not done.

This is a question that comes up in our teams also. Our backlog items are a mixture of feature work and defects.  For velocity purposes (only to get a rough estimate of what can be completed in a sprint), I lean towards pointing defects, else a "true" velocity is difficult to determine. (Defects can be from years ago, untraceable, be from other teams or unrelated work etc. thus not always easy to "undo" a past backlog item.) 

However some teams view pointing/estimating defects as cumbersome  and waste.

I am keen to see what other people's opinions are on pointing/estimating defects.

My team uses story points for the purpose of estimating whether an outcome can be developed within 10 days (our Sprint length); new requirements are estimated the same as regressions/bugs (could this be classed as refactoring).  Story points provides the team with an opportunity to discuss and forecast the effort to develop a requirement in the upcoming Sprint.  IMHO, the discussions between the team when discussing sizing to understand the requirement, are more valuable than the story point estimation (or whatever estimation method is used).

Story points are estimations of tasks made by developers using their best guess.

Not metrics, not evaluations, not the results of any kind.

In fact only reason story points exist is because they are useful for burn down charts, they have no other use.

Having said that if tasks of fixing the defects(solving technical debt are part of Product backlog developers can estimate them in story points(or in other techniques if they want).

Consider that the Product Backlog is an ordered list of what is needed to improve the product and is intended as the single source of work for the Scrum Team.

Product Backlog items (PBIs) are the elements within the Product Backlog that represent the improvements. Distinctions between PBIs being stories or bugs or tasks or whatever are of our own making. Really, they are all PBIs, and can be treated the same way. An approach can be...if it enters the Product Backlog, treat it as a Product Backlog item. 

The distinction I tend to make is when it comes to flaws found with in-Sprint work. If a defect is found with a PBI being worked on in the Sprint, it is really just part of the work of the PBI and has already been taken into account when sizing that PBI. No need to size this. 

@Ryan stole my thunder.  :) 

I agree with him. When people start trying to classify things, they also tend to treat them differently.  My opinion is that everything in the Product Backlog is an Item.  All Items are treated the same way. All Items have 2 values, negative as long as it exists in the backlog, positive when it is included in an increment.  Makes it simple to remember and easier to do.  Every Item will get the same consideration when the Product Backlog is ordered.