By implementing both
IList<T> you allow your type to have maximum (or at least, more) generality. Code that expects an
IList (generally older code that predates the introduction of generics) can accept instances of your type.
In game development, this isn't as much of a compelling reason as it might be elsewhere. Most of the time backwards compatibility with some of the legacy APIs that accept non-generic collections isn't a huge deal. If you're writing framework-level code, especially framework-level code you intend to distribute to the wider internet (so you don't know precisely who will be consuming it and what their personal needs will be), that provides a stronger rationale for why you'd want to implement both. That may explain why you've come across it in a lot of available frameworks.
If you're just writing game-specific, non-reusable code? It's not a big deal (and you should prefer to implement the generic version as its nicer to use).
On the other hand, the extra work needed to implement the non-generic version is usually quite small, so maybe why not?