I do not think that there is publicly available research specifically on the pull-to-refresh feature. However, I synthesized some similar materials and came up with an answer of my own.
Taps vs Swipes
Swipe gestures are faster and easier, but often considered "hidden."
Florian Weil's research on touchscreen gestures concludes only that screens are best paired with thumbs as opposed to the whole hand or arm. Pulling down (usually with a thumb) fits the bill. Likewise Jianwei Lai's findings point out that swipes are more reliable than double-taps and faster for the user. UserInsight weighed the pros and cons between taps vs swipes in general which coincides with your question's observations:
Our research has shown that often the only thing that causes people to swipe is the knowledge of the convention of swiping itself. [...] Users who are unfamiliar with the convention of swiping may completely overlook the interaction and miss features and functionality because of it.
Twitter's Delicate Balance
Enough said: Twitter invented pull-to-refresh, yet they supply a button.
In my original draft of this answer, I pointed out that
Twitter pioneered the pull-to-refresh gesture. When you use twitter today, there is a button presented as an alternative method however. Despite that the gesture was absorbed into the mainstream by Apple. If there are new tweets in your stream, a button will show either at the top of the screen which you can tap, or at the bottom if you're scrolled down far enough. It's a very tiny button, but because the pull-to-refresh feature exists they can afford to do that. The button at the top still gives you instructions. It reads "Pull to refresh" so you know how to work the gesture. And once you know how to use the gesture you may not want to go back to using anything else. Twitter's nailed a delicate balance between satisfying a user that wants a button, educating a user that might not know that pull-to-refresh exists, and satisfying the power user that assumed it was there all along by making the reminder UI so small that it's impact on the experience is negligible.
Pull-to-[Action] Fragmentation
A 2013 Fast Co.Design article scythes at the pull-to-refresh feature because despite being innovative, the pull down action was ubiquitous and being used for things other than refreshing a page.
Pull-to-Review
When users open Jawbone’s Up app, for example, it automatically syncs and updates with the company’s companion activity tracking wristband, UP24. So now, when users pull-to-refresh, Jawbone instead displays a bite-size, digestible summary of what data was just transferred when the program synced.
Pull-to-Search
on Apple's home screen in iOS 7, pulling down now gives now users access to a search box
Why [Action]-to-Refresh At All?
Because losing your place is annoying
HTML4's <marquee> was pretty popular in the late 90s. The trouble with a ticker is the same as Twitter's old live stream: as you're trying to read, the text keeps moving away from you. As more applications developed ways to stream in data, there's been a growing number of developers trying to figure out the technical issues of how to make applications reactive. Reactivity means that as soon as a change is made anywhere, it's propagated everywhere else—think Google Sheets shared between 2 or more users simultaneously. But instantly updating your UI to reflect changes from other users sometimes is an annoyance. The designer needs to make sure that the user won't get disoriented. There are lots of people trying to figure out how to take advantage of reactive frameworks wisely because too much reactivity isn't just disorienting, it also is expensive for the server, the browser, the app, the user's data plan, etc. Some related subjects that might interest you would be "Optimistic UI." In an ideal optimistic-ui method of refreshing, you would silently get new posts as they are ready, contents and all. Then when the user decides to refresh, you present the stuff in RAM instantly, while double-checking the server for anything else. If there's anything that was missed, update a second time then stop.
A Final Thought on Infinite Scroll
Think for a moment about infinite scrolling. The user has a batch of content, and when they scroll down, the next batch is fetched. In the best case of Infinite Scroll, the user doesn't notice that the computer is fetching more batches. Typically, the scrolling direction is down as the user travels further into the past. The end of the stream is the oldest piece of content, and it's usually understood that the user can stop scrolling.
Now consider the opposite. What would an upward scroll that goes in to the future look like? Almost exactly the same with one caveat: reaching the end of the stream. When the user reaches the present—now—how do they know that the "now" that they're looking at is actually "now"? You could design the content to keep populating upwards while allowing the user to keep their place until they're ready to keep scrolling up. And just the same, you could give them a sanity check so they could ask on command if there is anything newer than what they're looking at. And if scrolling for more is already in place... scroll to refresh seems like a natural pathway, and I think that's maybe why we're all so comfortable with the idea of pull-to-refresh.
