We've been at it before, inconclusively. Even then, under DBObjectCollection Class, arxmgd.chm says:
When a DBObjectCollection is disposed, it looks at the set of unmanaged objects it holds, and the set of wrappers it has generated. For those objects with wrappers, it assumes the wrappers will manage the lifetime of the object, and it does nothing. For those objects without wrappers, it will delete them or close them: it takes responsibility for object lifetime.
...
Regarding:
"Alternatively, you could wrap the DBObjectCollection itself in a using statement, which would take care of disposing the objects contained when leaving its scope."
I took the word "Dispose" to imply managed wrappers rather than pointers to native AcDbObjects, and DBObjectCollection (as the docs imply) doesn't call Dispose() on managed wrappers or delete native AcDbObjects for which managed wrappers were created.
For the items in a DBObjectCollection for which managed wrappers were created (which happens the first time an item is accessed via the indexer or the enumerator), the managed wrappers for those items must be treated the same way that all managed wrappers for AcDbObjects that are
not database-resident are treated (e.g., it is absolutely mandatory that their Dispose() method be called to prevent them from being collected by the GC).
it is important to be sure DBObjectCollections are properly (perhaps explicitly) disposed.
Yes, because if you don't call Dispose() on a DBObjectCollection, the destructors of the native AcDbObjects it contains that are not database-resident will be called on the thread on which the garbage collector runs, where AutoCAD API access is limited or dangerous at best, and that can easily lead to a fatal error.
All of this absurdity is largely due to the quirk that results from the fact that the .NET garbage collector runs on a non-AutoCAD thread where AutoCAD API access is not fully-supported. Because the destructors of some native objects can make calls to AutoCAD APIs that are not thread-safe, the managed wrappers for those objects must always be disposed (from an AutoCAD thread, where most managed user code runs), to ensure the destructors of the wrapped native objects execute on that same AutoCAD thread.