The easy pattern of graph structures is handled by the easy implementation of adjacency lists, which is how you should have been implementing it in other languages too. The specific incompatibility is with the naïve hand-implementations of these structures; the specific thing Rust does not optimize for is toy code.
You know nothing of what I'm programming. You don't know when, whether, or how my program accesses or deletes data. You don't know what domain I'm in, whether I'm on a team, or what our priorities must be.
And yet, you proclaim that your approach is how I should always do it in any language, in any situation.
It strikes me as particularly convenient, seeing as that's the only approach that the borrow checker can reason about.
To make it more concrete: if we apply your solution everywhere we run into this problem with the borrow checker, it can flatten a lot of our program's (non-temporary) state into basically relational tables. Sometimes that's okay, but for a lot of situations it can be bad for encapsulation, velocity, and modularity.
I agree with the sibling commenter that the parent poster was likely using the impersonal you. It is true that we don't know anything about you. You haven't volunteered any specifics, so we're kind of forced to guess if we want to try and respond in a productive manner.
To that end, I think that they chose a very good example. Abstractly, doubly linked lists are a special case of undirected graphs. So pointing out that a naive graph implementation is generally sup-optimal, and that usually one can more effectively model them using different data structures that Rust (and functional languages, and databases, and files, etc.) can handle just fine, neatly addresses problems that one might solve using a doubly linked list, as well as a whole host of other cases, in a single stroke.
