Just responding to a comment with "No" is generally unhelpful to both the reader and the writer, so I can imagine getting a little annoyed by it. There's a few things I've done in the past to get more information out of people (although I've rarely worked with people who are actively unhelpful)
Remember that the goal of a PR isn't to show off how good you are (on either side), but to make sure the code is solid, maintainable and as good as it's going to be. So respond from that feeling with requests for more information.
My first response question in this case would probably be "Can you explain why it can't be used?" to understand their reasoning. This is important, because if I don't get it, and I need to write a similar feature, I might decide to use that method and then waste time (or worse, create bugs) learning about why I shouldn't have. (You can add however much of that additional explanation as you need).
In a case where I figure it out for myself between the initial comment and the follow-up question, I would just add a comment saying "I think I see why I shouldn't use it; is [this] the reason?" and see if I got it right. That way, the other side doesn't have to fully explain it. Some people really don't like to do that (although it ought to be part of your expected workload in a senior position).
Additionally, if the reason for not using a function is technical and obscure, but the function seems like a logical better fit for the situation, my next follow-up would be "Can we make it more clear from the code why we don't use the other function?".
Since we're trying to make the code as good as it can be, warning any future developers about this obvious fix that won't make things better seems important. The next developer to look at this code won't see the PR and the discussion, and might decide to refactor things to make them better.
If the reason for not using the function should be obvious to people using it and I just didn't know about that feature before, that means I learned something new. So I'd follow it up with a simple "Thanks, I didn't know about this yet.". Yes, even if I figured it out myself, since the other developer was still the reason I looked into it.
You'd be surprised how often people will become less crass and will take time to explain things to you, if you thank them when they teach you new things. And even if they don't, you'll feel better for still being a friendly colleague to them.