It isn't, though, and demanding a portfolio is almost as terrible a practice as Cracking the Coding Interview style interviews.
I have to believe it "is neither engineering nor science, and is purely creative"? Only those extremes? I believe it is some of all 3 and I don't think requesting (i.e. not "demanding") a portfolio or prior work is any more unreasonable than not asking for it.
Demanding a portfolio isn't a great hiring strategy simply because a lot of people's best work isn't out in the open. Who would demand a portfolio from someone like Mike Acton? It'd be enough to know what he's worked on and talk to him. And at the same time requiring a licensing proxy is no help either, he never went to college AFAIK and that'd probably be a minimum requirement for most actual licensing proposals.
On top of that, many electrical and mechanical engineers are not licensed because they don't need to be. (Everybody likes to jump to the civils in these discussions and forget about us, since civils are basically required to be licensed.). EEs and MEs don't get put through the same bullshit that this industry puts developers through.
Is your "portfolio piece" spaghetti code or well-thought-out modules? Is it doing something recursively that shouldn't be? Do you have elegant code or brute-force solutions? Is it write-only?
All of these can be seen in a portfolio or side project if you choose to look.
It's certainly not a science, and it's very rarely engineering. About the creativity, it's a craft. There is some creativity baked in, but about the same amount as for mechanics or carpentry.
Do you think a 10 minute scan of an arbitrary GitHub account is the same? I say decidedly not.
Perhaps more tellingly I've interviewed people with seemingly impressive GitHub accounts who were just terrible. That experience leads me to believe it's easy to set up a GitHub that "looks good" without having the chops to back it up.
There are a lot of great engineers with empty or "bad" Github profiles.
1. They care enough to have a Github profile
2. I can see their actual interests.
3. I know they're interested in random experiments
4. I can see if and how they treat their projects. Are they dedicated maintainers, or do they just fire off one-shot projects without ever deciding to maintain them?
And a whole lot more. A person who maintains a single shell script project with diligence is worth more to me than a thousand developers with bullshit lisp and haskell repositories.
Yes, there's a bunch of great engineers with empty or bad github profiles out there. But those engineers aren't showing me that they're great engineers. The ones with a single or few well-maintained projects do.
I just know a lot of people find side projects fun because they can let loose a bit and try out random stuff that may not be their "best" code.
This is still a huge asset. It's important for a person to want to grow and learn new stuff. When it comes to hiring a person, there's a whole lot of stuff that's important. Maintaining a long lasting project is one of them. Having an interested in fun side projects, also. It doesn't have to be good code. In fact, I have my fair share of "this project is not maintained and should not be used in production code" repositories. That's just shorthand for "this code sucks".
Many people have their favored hiring "hacks", and they almost never actually signal for the things they purport to. It's way too easy to fall into confirmation bias or overstate one's ability to judge others.
For example, an applicant that goes through the trouble of writing a thoughtful, reasonable README for every one of their projects signals a positive quality.
When comparing two candidates, that's certainly something to consider.
You can't because design isn't about style, it's not art. It's about solving problems and increasing your employers profit.
Perhaps the best solution would be a unionized right to proper credit to developers like in the film industry.