The search text input is disabled until the RSS is fetched. So it's because of UI design. If there's an error, the search box will stay disabled. Users are more OK with something being disabled, then something appearing to work, but doesn't. It also makes the search slightly faster.
Pulling the list on page load makes sure the code responds fast when the user starts a search
I guess, but it then needs to load every page referenced in the RSS so you're preloading only one file of a much larger count. And you're adding the weight of the RSS file for every visitor, even if they never do a search.
The user should be able to consent (or not) to expensive operations like that.
If they have js enabled they already did.
True, but there is some validity to the point. On a large site you might burn a lot of your mobile data allotment with one search. That's not intuitive or obvious. Might be nice to implement limits and a more button in the code so it doesn't scrape the whole site at once.
You could defer it until they start typing in the input box. Still better than waiting until they click search, and doesn't waste bandwidth for the average case.