I've been using Hibernate for a few years but have only used it with annotations, and by setting the connection parameters in my code.
Am I "missing something" by not using the XML files? Are there important capabilities available only in XML? Are there situations or patterns where it makes sense to use the XML?
Doesn't Hibernate use the EJB3/JPA standard annotations? If so, I can think of at least one reason to use XML: those annotations don't have all the capabilities of Hibernate.
Example: Hibernate can define a "native" type for IDs. This will create an auto-increment field on MySQL and a sequence on Oracle. There's no way to do this with JPA annotations that'll work in both situations.
Also, XML is pluggable. Annotations aren't. This might matter for you if you ship to multiple database platforms and have different config for each one.
XML has fallen out of favour with a lot of developers and for that reason alone I think a lot favour annotations. Thing is, you have XML anyway (in the form of a persistence.xml file and possibly others). It's a bit like six of one, half a dozen of the other.
Annotations are a great way to quickly configure Hibernate. But one of the key features of OR mappers like Hibernate is that you keep your domain model "persistence ignorant" your objects don't need to know anything about where and how they are persisted. Some may argue that using annotations breaks that. And in situations where persistence is just one of many concerns it makes sense to keep things separate.
Another reason can be that domain objects are persisted differently in different situations, you can have multiple databases used by one application or even more applications that use the same domain model.
I think it's pretty safe to say that you're not missing out on anything.
If there are any capabilities in XML that can't be represented in attributes (and I believe there are some rare cases) then you still have the option to use [RawXml] and write the XML in the attribute. So you can't possibly miss out on any functionality.
It might make sense to use XML if you have enough programmers in your team who simply prefer to manage separate files or if there is a genuine need to edit xml mappings on the fly. Xml mapping files are probably easier to manipulate for very complex mapping and they can contain useful information (comments on fetching strategies etc).
There is also the issue of architecture, where some people argue that separating the mapping into XML files provides a better separation between business-related code and instructions on how it is persisted.
I'll mention that the only drawback I have found to annotations is that I have to embed the relevant annotations in the classes of my domain model, and that therefore whatever programs use the domain model need to have access to the API.
However, for a variety of reason I don't directly persist my domain model, but rather have an analogues (but somewhat different) "persistent domain model" that gets persisted and is only in the server so this was not a big issue.
There's almost nothing you can't do in annotations that you can in XML. I can't even think of anything atm. You can try conforming to JPA but I've found the JPA API is quite limited. Still, that just means you use non-standard Hibernate specific annotations.
There are several comments that state that hibernate annotations pollute your domain models, but these are tightly coupled to your database layout anyway. In any code that is not database driven you would need to build an intermediate layer anyway. In fact, IMHO a lot of web apps should use intermediate value objects that copy only the data required to the presentation layer. Instead, many use the open session in view antipattern.
Lastly, while xml configuration is flexible, common practice shows that whenever we're editing the xml files we're almost always editing the java source files as well. This is just another argument for moving the configuration closer to the objects, i.e. into the annotations.
Don't want to repeat anything that has already been said but I use XML style configuration to keep it separate from my code. That is mostly done to my personal preferences and at the end of the day it wont matter :) Another thing you can do with the XML is to have hbm2java generate your code for you and I do like this as well, but again is it an advantage; probably not.
So I'd say it is just a question of what you prefer.
I don't know if you're including named queries within configuration, but I tend to put them in XML files, even if I consider it raises the risk of errors between the entity and its queries. It allows to tune a query without having to recompile the whole application.
Using XML instead of annotation could also avoid a JPA dependency in your UI layer if you reuse your entities from business to presentation layer, but I'm not sure the argument is relevant.