To some extent, yes, the person matters. But rarely is it that simple. The three concerns are: topics, proposals, and people. There are topics that I know I have to cover. But on a single topic I might have several different proposals. I want the best one. But I also want to get a good distribution of people--I could almost have a Perl conference full of diverse topics with nobody but Damian and Dominus, but attendees would lose (I think) more from only having two points of view than they'd gain from having two great speakers and a lot of different topics.
Big names from p5p, mailing lists, CPAN, whatever, tend to have a "here's what you should be doing" point of view because they often created the technology they're talking about. But the not-famous in-the-trenches people often share real world-knowledge, telling attendees "here's what you have to do to make it work" without any of the head-in-the-clouds thinking or theoretical concerns that sometimes the famous people are prone to. (hoping I'm not making myself enemies!) It's important to get both sides--testing and QA used to be an academic exercise, but as my email bungle shows, it's pretty bloody important in the real world! The nature of technology is that what's far-out today is commonplace tomorrow, so it's important to have that mixture of "what you need to know to do your job today" and "what you'll need to know to do your job tomorrow".
Anyway, back to juggling topics, proposals, and people. For example, this year I had two proposal for Perl optimization tutorials: one from Mark Jason Dominus and one from Robert Spier. Both had submitted other talks, so it wasn't the case that I absolutely had to pick their tutorial to get them into the program. Dominus had a lot of other talk and tutorial proposals, and Robert had two or three others.
Both proposals were strong. I know that both presenters know a lot about the area--Robert's been doing a lot of a Real World sysadmin stuff lately (for perl.org, in fact) and Mark's got great insights into the internals of Perl. So in the end I selected Mark's tutorial, and as Robert was already speaking as part of RT and Single Sign-On talks, I knew the attendees would still have a chance to hear from him over the course of the conference.
This was a rare example because most proposals aren't equally good. If you don't include an outline that'll show me what you plan to talk about, or you do have the outline but it's missing a key component to the field, or you don't tell me what the benefit to attendees is, you're making it much harder for your proposal to be the best.
So yes, you are at a disadvantage in this game if I don't recognize your name and think "we must make room for him/her". But even then it's not a given. Inevitably, each year there is at least one famous Perl person who didn't get selected and is pissed off about it. But space is limited and sometimes I simply can't cram in everyone who deserves to be there. And there are dozens of non-famous Perl people who wonder how the heck they could have done better.
To some extent you're also at the mercy of how I feel about a topic. For example, I tend to lump database proposals together in my mind. If I get three proposals, one on DBD::something, one on DBIx::something else, and one on how you used Perl to reduce your DBA workload to something you can do from the beach via SMS on your cellphone, they're probably going to be duking it out for however many "databasey" slots I think I can give. And that number is affected by the content in the other tracks--this year there's an awesome MySQL and embedded Perl talk in the MySQL track, so I didn't feel the need to have a MySQL and Perl talk in the Perl track.
It's a complex juggling system, part intuition and part method, and I'm sure it's cruelly unfair. If you've written to me asking "why didn't I get accepted?" I'll be replying over the coming week, explaining how far your proposal got and how you could improve the outline, description, or title.
While I have your attention, though, the single best thing you can do is give your talk or tutorial a meaningful title: "Effective Perl Debugging Strategies" is so much easier to see the importance of than "Kickz0r Your Fl34z: Debugging a New Millennium". (I made up that title) There were some talks and tutorials that I suggested new names for, because they were good but it would be hard for someone skimming the list to recognize how good they were. But I'm sure that some worthy talks and tutorials were inadvertently penalized because "Doing Better Perl" just didn't jump out at me from the lists when I was juggling the last twenty candidate talks and only had five slots to put them in.