Generic containers can be a time saver when having a item, and a strongly typed list of those items. It saves the repetitive coding of creating a new class with perhaps a TList
You wrote about backwards compatibility... this is my biggest concern, if (like me) you are writing libraries which should better compile with most common versions of Delphi.
Even if you're using only XE for a closed project, you are probably making some custom libraries of your own, even if you never publish the code. We all have such favorite units at hand, just available not to reinvent the wheel for every project.
In a future assignment, you may have to maintain some older code, with no possibility to upgrade to a newer Delphi version (no money for the 1,000,000 code lines migration and review). In this case, you could miss your XE-only libraries, with shiny generic-based lists...
But for a 100% "private" application, if you are sure that you will never have to maintain older Delphi code, I don't see any reason not to use generics. My only concern is the duplicated code issue (as quoted by Mason): the CPU cache can be filled with unnecessary code, so execution speed could suffer. But in real app, I think you won't see any difference.
Note: I've just added some new features to my TDynArray wrapper. I tried to mimic the sample code from EMB docwiki. So you could have generic-like features, with good old Delphi versions... Of course, generics are better for working with classes, but with some arrays and records, it just rocks!