This depends totally on your context. How important is it to the user that the list is always current? How long does a refresh take?
Extreme case 1: Totally important. For example, you are listing stocks available for purchase, with prices. Then you have to display current information, period.
Extreme case 2: Unimportant or even undesirable. Imagine a company which promises that any orders posted until 11 AM will be processed the same day. You have a worker who refreshes the list of orders at 11 AM and starts working on them. If the list was kept current every time he goes back to it, the list filling with newer orders will be somewhat impractical, assuming he has to process all of the old ones before he needs to pay any attention to the new ones.
Most cases will probably fall somewhere between the two extremes, but barring unusual circumstances (which can probably be solved better than with a non-refreshing list, like my example above), users will have a preference for current lists.
As users also have a preference for promptly responding systems, there is a trade-off between how much freshness and promptness the users get. But there is no general rule that users always prefer one over the other. Microeconomics offers a very elegant analysis of this type of problem with indifference curve analysis.
I'll skip the explanation of the microeconomic model and come to the conclusion: Your perfect solution would be to try to find a technical solution which will offer more of both things users want. Maybe you could implement some kind of smart caching which asks the server if there were changes to the list (quick roundtrip) and only refreshes (slow roundtrip) if there were changes, else shows the old list (instant response)?
If you can't come up with a technical solution, the ideal point on the freshness vs promptness curve is determined by the shape of the users' preferences, which is dependent on the context, as described above. It is only you, who is in the middle of the project, who can know or find out which one they value more. If you cannot predict their preference by reasoning, you will have to find out their preference by live user testing.
For live testing, you can either invite users to use the system in front of you and observe their reactions, plus ask them for feedback. Or, if you have a live system already, do an A/B test and collect relevant usage metrics for a variation with a current but slow list vs a variation with an old but quick list. The first is better for explorative analysis, as you frequently learn things you didn't expect. But it is costly and delivers very few data points. The second option is cheaper, and can be used well to confirm an existing hypothesis due to the large numbers, but won't give you any further insights beyond what you thought to measure.
Finally, there are some empirically confirmed numbers for annoyance threshold. This Nielsen article is probably the classic one. If you think that your loading times fall below some bad threshold (and you will have to be the one to decide which threshold you are willing to live with in your application), you can just decide to give up the whole costly optimization.