I'm wondering what makes you feel confident about the use of linked lists in all of those components.
Mind you, most of those will be written in C on a typical Linux installation, and linked lists happen to be one of the two collection types that are relatively easy to use in C (the other being a flat array), so I will concede that some software is using linked lists out of desperation, rather than it being the correct choice. :-)
> I'm wondering what makes you feel confident about the use of linked lists in all of those components.
Of all of those mentioned I literally looked up their source repositories up and searched for obvious indicators like "linked", "list", ".next" or "->next" and then verified that I was indeed looking at one or more linked lists. Where does your confidence come from? Oh right, you already mentioned it: it's based on your experience of the projects you've worked on.
The rest of your reply is just moving goalposts, mind reading and a glaring category error. Get back if and when you have something useful to add.
Not really desperation, it's just easier. Sometimes this is where perf doesn't matter, any choice would be fine, a linked list of the up to 4 Doodads won't be meaningfully worse or better than a growable array of the 4 Doodads, or I dunno, a HashMap from index to each of the four Doodads. Stop worrying about it and focus on the real problem.
In larger C software sometimes a use of linked lists is costing meaningful performance and a growable array type would be a huge win - but the other side of the coin is that sometimes in these perf critical environments a linked list actually is the right choice, and a C programmer might luck into that since it was the first tool to hand while say a C++ or Rust programmer might take longer to realise that this data structure is the best option.