Let me give you my take as someone who has had to hire a lot of developers. Firstly, I'll say it depends a lot on the person doing the hiring. Different people will look for different things.
For me though, any practical experience that you can show alongside your resume/CV is helpful for a few reasons:
1. If I see code of an excellent standard, I know I just need to use the interview to make sure you really did write it yourself, then if you're a good personality fit, you're hired. This makes my life a lot easier because it's very hard to tell if someone will be a good coder without seeing them code. Not everyone is willing to do a practical trial, and not all employers have time to organise these either.
2. It lets me see if any assessment you give of yourself agrees with reality. Some people understate their abilities, but most overestimate themselves greatly. If I know where you sit on this spectrum I have a better idea of what to expect in terms of mentoring requirements, how to approach the interview, etc., to figure out if you are competent and whether any poor judgement is a problem, or just typical egocentrism.
3. It gives me things to talk about in the interview. Like, "I saw you used X, why did you do that and not Y?" Usually it's when people can actually start talking about things like this that you can tell if they really understand what they are doing or not.
So, I wouldn't be put off by the idea that you don't have a lot of open source contributions out in the wild for employers to look at, simply because it may not matter to everyone. However if you do, it's always of value and something you should highlight.
In any case, don't underestimate the value of being able to show some work you have done. If your best work is closed source, try to get permission to show some of it to potential employers, while bearing in mind that they will be very busy and not hoping to wade through a ton of code figure out if you know what you're doing or not. It's an extra resource: if your skills look interesting, it allows them to see some evidence of what you've done, and poke around for interview talking points.
Often just knowing the type of projects you worked on and having proof of your contribution is enough to tell if you are the real deal or not. So if you can't get access to sources, just indicate the projects, say what you did and try to get some evidence, like endorsements/references from colleagues. If you can't provide evidence, expect the interviewer to grill you on this: it will soon become apparent if you were exaggerating your contributions.
The most important point is that if your CV/resume does not look good, they won't want to look at your code anyway. Don't shove it down their throats. Start off by selling yourself as concisely as possible, and use these kind of extra resources as evidence to back up what you say.
What I like most about these Github resumes is not so much the fact I can see individual contributions, but that I can very quickly see a project history and % breakdown by language, which is what I'd expect to see on a paper resume, except here I know it's based on real data and not just something the candidate may have just made up. From data like this this I can tell within a few seconds if that person might be a good fit, and from there I may decide to go investigating further.
Just remember that if you apply for say, a Ruby job and 90% of your open source contributions are Python, you probably want to tell the employer somewhere e.g., "I work with Ruby in my day job but most of my open source contributions are in Python". Only if the data is misleading though, like if as you said you have some open source contributions, but not enough to be representative.
TLDR: Employers are busy. Within a few seconds, they want to know "does this person appear to have the skills I am looking for?". If that answer is yes then they may spend more time re-evaluating it, based on any evidence they can get. Source code is usually the best evidence a programmer's ability. Less up-front evidence means any interview will be a lot more hit-and-miss: interviews alone are not a good way to assess coding ability.