The idea about lazy loading (always) leading to performance degradation is incorrect. It depends on the requirements and the implementation by the developer.
If you're designing an API for 3rd party users (where each unique request to the API is served through e.g. a context), it may be appropriate to allow the context to navigate the object graph and retrieve objects that were modified (even deleted) post the creation of the current context - but when the context attempts to change data, the context is aware of stale data (i.e. by comparing timestamps or a corresponding mechanism).
For ASP.NET applications, the above pattern works quite well because you'd usually want the benefits of lazy loading (for performance issues and memory pressure) as well as allowing the particular request to complete without sporadic null references (i.e. when navigating Order > Customer where the customer entity may have been deleted post the creation of the current context).