Some points:
Most Xilinx FPGA's have the ability to configure the fabric flops as a gated latch rather than an edge-triggered flop. These are quite robust latches and work as you might expect a gated latch to work. Xilinx's own XST synthesis is happy to infer them for you (with warnings, because as mentioned elsewhere, latch inference is often unintentional).
Even these beautiful hard gated latches will have problems if your code generates the enable signal using a combinatorial decode of several synchronous signals. Furthermore, the gate input needs to come from the clock pin of the slice. Since the gate signal is rarely a system clock line, you often lose a lot of slice logic because it cannot get another clock routed to the same slice. Probably not a big issue if you use a latch here or there in an otherwise synchronous design, but it makes a mostly asynchronous design very large in terms of slice footprint.
The same parts will fail miserably if you try to build asynchronous sequential logic using just the LUTs. One reason is that you cannot prevent the tools from removing coverage terms, short of directly instantiating the LUTs with your own INIT attributes (LUT contents).
Xilinx *does* guarantee that a LUT with one input switching will not glitch going from a 1 to a 1 or a 0 to a 0. There are no guarantees when multiple inputs switch mostly because it is impossible to route such that they switch at exactly the same time.
The timing analyzer also tends to be overly conservative when determining timing through a transparent latch. One of the points of the latch is that it can add to setup time at the next flop by passing through the input while the gate is "open." The tools however will look at the gate enable path as a worse case rather than the data, and in some cases falsely state that your timing will not work. This leads to a lot of hand analysis of the timing.
In general, the Xilinx tools are very solid and give reliable results when your design is completely synchronous.