This document is linked to from elsewhere, as I need to refer to "technical briefs" often.
Technical briefs are what Microchip calls the sort of documents that most of the industry refers to as "app notes".
Well, that depends.
You see, "technical brief" is a very apt term - it covers the wide range of usefulness and detail that can be seen in the technical briefs. Some of these are briefs as in a briefing, like what would be given to a military commander when making strategic decisions, filled with valuable insight and information. These are sometimes not the easiest documents to follow, but they are the most useful class of technical briefs. I suspect that they were written primarily by an engineer, rather than a documentation person (though, since you can read it, it was edited by the documentation folks).
Other "technical briefs" have less of the "technical" part, and are simply "brief", that is, short. This is not always bad, and brevity is not a sin in and of itself - but many times these "brief" documents cover in 4 pages enough material to fill a dozen. The "product brief" is the extreme of this - in the past what is now called a "product brief" may have been called a "datasheet summary" - that is, pages 0 to the end of the I/O multiplexing considerations section, plus the boilerplate at the end of every datasheet. That boilerplate is where they cover the matter of . These give the impression of having been written by someone who is familiar with the peripheral, but has little experience actually using it, and these are generally not all that useful, though they may give a broad picture of how some aspect of the part is intended to be used, there are thorny problems that they neglect to cover fully.
There are also an unfortunate third class of "technical briefs" that are even less helpful. Here the name is still apt, but in this case, it's in the sense of the article of clothing of that name. These "briefs" serve much the same purpose as said clothing: they cover one's ass, but that's about all. This, I think, is what happens when nobody who knows how the feature actually works can be made available to write the tech. brief, but customers aren't happy to see no additional documentation on it, so they cannot just not-write it. So someone who doesn't really know what the feature does or how to use it is forced to write a tutorial for it. That goes about as well as you'd expect, and usually just ends up paraphrasing the datasheet. Like a pair of briefs, while these might be a starting point, you'd better have more than that if you're hoping to go anywhere with it.
So, between the very brief "technical briefs" which are of limited use to those unfamiliar with a feature, and the "briefs" that are of little use to anyone, only a minority of the "Technical Briefs" are worth reading. However, among those that are, there are some really insightful and solid ones that are of great utility. They cannot be distinguished without reading them, but once you start reading, you very rapidly will realize which kind you have.
On the product page for the applicable parts, in no particular order. That means that the list will contain a mixture of not only those three classes of technical briefs, but also Atmel's old AVR App Notes. A few of the old app notes are useful and still relevant. The majority aren't though.