Perhaps RDFa isn’t the answer to all our semantic problems (Some bits are Drupal specific, but its worth considering):
1) RDFa isn't explicitly supported by Google in their documentation for their consumption of Schema.org. I know that someone will point out that increased institutional support is coming in the not-too-distant future, but it has been coming for at least a year and a half now, and it also isn't clear to me whether that support will include docs in Google's Schema.org documentation (as opposed to Schema.org itself).
2) It is the most complex option. This makes it harder for users to figure out what's going on and harder for them to debug. It also means that we have bugs which have gone unresolved for years.
3) To do it right, it will require that every field formatter's RDFa output be tested and that some include code specifically for handling RDFa. The RDFa 'feature' that we used to handle attribute placement genericly in D7 simply doesn't provide data that is reliable enough. RDFa Lite copies microdata's processing model, which is more explicit but also requires that the attributes be placed in field formatters for many types of field, as I've pointed out before.
4) It makes the data less accessible to most consumers. In order to get data out of RDFa-enhanced HTML, you need a special tool, an RDFa parser. Most developers are not going to be familiar with RDFa parsers, much less use one. Additionally, even if you use one, the RDFa 1.1 parsing algorithm is super complicated, so if you run into a problem it can be hard to tell whether it's a bug in the data or in the parser.