Representing the list may or may not matter for a specific algorithm, but what does a list has to do with a stack/queue?

A list is one of the possible implementations, you could use, to implement a stack or a queue. Anotherone would be an array.

If you insert at the end of a list and take from the front, that's a queue.
If you insert at the front of a list and take from the front, that's a stack.

Ok, that's understandable but if it makes any sense, can you go without a stack or queue for a list?

Don't undrstand it very well what you mean. A linked list, if it's that you mean by a "list", is just that, a linked list. Even excel uses that to implement its spreadsheets.

A list is a list - an ordered sequence of values. Use it for whatever you want. Two possible uses are to implement a stack or implement a queue, but you don't have to use them like that. For example Some list implementations (eg linked list) can grow or shrink to fit the amount of values, and efficiently support removing or adding values in the middle, and so may be a good substitute for an array in some applications.

I mean any type of list, like a linked list, doubly linked list, or a circular linked list that is to be writtin in C.

So, that can be in the middle of the list.

Appending to either end of a list/array is much simpler than inserting in the middle. Appending to the end of a list has the lowest overhead.

Not always - it depends on the implementation of the list. For example a linked list has the same overhead for inserting an element in any specified position (indeed, if the implementation only keeps a ref to the head node then you have to search sequentially to get the end node, which gives it the highest overhead)