Sentinel head and tail nodes (with value: null) eliminate every 'is this the first or last node?' branch from the rest of the API. Insert and remove both become four pointer assignments with no special cases. The trade-off is two extra nodes in memory, which is negligible for any list big enough to care about doubly-linked semantics. Returning the inserted node from pushBack lets callers cache a handle for O(1) removal later, which is the operation LRU caches depend on.

When you already have a reference to the node (e.g. from a Map<key, node> index), removal is four pointer reassignments and runs in O(1). The doubly linked structure is what makes this possible: a singly linked list cannot remove a known node without scanning to find its predecessor. Pair this with a hash table that maps keys to nodes and you have the kernel of an LRU cache (see the dedicated LRU template entry for the full story). Setting the removed node's prev / next to null is bookkeeping that helps GC and prevents accidental traversal.

Walking the list backwards is the second feature that comes free with a doubly linked structure. Wrapping each direction in a generator lets callers use for..of, spread, or destructuring without exposing the raw nodes. This is useful for editor cursors (next / previous word), browser history (back / forward), and any sequence where the user can traverse both ways. The same generators work for partial walks (start / end at any non-sentinel node), since the loop condition is just 'not the sentinel'.