Regarding points 4 & 5, I think it really depends on what stage of company you are, and what kind of work you're doing. When you're making your 4th, 5th, 6th hires into an engineering team, you normally want a pretty diverse range of skills.
We've had front-end guys work on SQL code and contribute significantly to our devops tools. People who are interested enough in programming to be constantly pushing themselves to learn new technologies are extremely valuable.
At some larger companies also, interviews tend to be "holistic" even when the roles are not. You might be hiring a frontend person but the interview panel will be consisted mostly of backend people. I've unfortunately been through interview cycles (from the employer-side) where this was the case.
Worse perhaps are when recruiters deliberately mislead the candidate into coming in. I've seen in the past situations where frontend or backend-centric people come in to interview for the exact opposite position, and are pissed off (rightly so) because they've made their specialization clear to their recruiter contact but was told the position was still relevant to them.
I'd only differ with you on larger companies wanting more holistic folks. In my anecdotal experience, large companies are usually hiring to fit somebody into a particular business process block and want ultra-specialized people for that block.
In my area it's not even uncommon to see job reqs for experienced people using very specific development tools as well.
It can get weird when that role is a new industry one, like less than 5 years, and they want a senior person for that role with 5-10 years of experience in it...which is clearly impossible.
(Of course, there are silly things that Google does like ask potential Product Managers algorithm questions; I am not clear how that helps.)
1) Be respectful of candidates: their knowledge, their background, communicating with them, and most importantly their time. You may think your startup is a very special snowflake, but to a candidate, it's application #107 out of 243. Nothing gets my goat more than a company that absurdly and absolutely wastes my time.
2) If a candidate makes it through a contact, that means they made it through a level of the interview process and were downselected and are now part of a smaller pool. That's how they'll perceive it, that's how you should perceive it. I've seen all kinds of nonsense about repeated interviews where the candidate thinks they're getting close to landing the job, but the company's internal processes are just getting enough interviews to fill out the hiring committee before rejecting the candidate.
3) If you're going to do the wrong thing and make a nepotistic selection, save everybody the time and energy and just hire that person from the start. Don't engage in kangaroo application processes just so you can claim it was competitive. It wasn't.
4) Have a solid idea of what position the candidate it interviewing for. Don't engage in "holistic" and speculative hiring where you hire a guy because he seems swell and you end up bouncing him around from position to position to try and make him fit.
5) Ask questions that are actually relevant for the work the person will be doing and might grow into. If it's a CRUD developer working on backend data stuff in SQL and Python, don't waste their time with irrelevant algorithm questions and score them based on their knowledge of node.js and functional programming -- or even worse, non-engineery things like how to negotiate a fulfillment center contract and keep inventory loss to a minimum. Chances are you need them to do lots and lots of X, not write bubblesort or regular expression optimizers or b-trees. If you do need them to do that kind of work, interview them for that.
6) If you want to have a quiz, or coding challenge or whatever, give them problems that represent the simplest possible version of what you need them to do. Fizzbuzz is a great example. It exercises very basic programming skills without spending time asking them to write a bubblesort. If they list SQL on their resume, have them write a very simple SQL statement. 9/10 can't do these basic skills tests and there's no reason freaking them out and wasting your time on more advanced questions. You already know that if they can't do these things they won't fit in.
7) Contact your candidates and reply to them. When they apply, acknowledge the application. If you reject them, be a grownup and at least send them a nicely worded email, "...wouldn't be a good fit here...". When you are looking for a job, and you don't know the outcome of an interview at a place you really want to work for, you might delay or pass on faster moving opportunities to wait it out. Rip off the bandage and let them know they didn't make it so they can close it out and move on. It's just common courtesy.
8) Don't be confrontational. Many engineers are terrible at the soft skills during an interview and are already freaked out by the experience. It's on your home turf, you have all of the advantage, and it's concerning something that might have impact on the rest of the candidate's life. Be a good host!
9) Interviewers need to show up or make themselves available by some alternate means. You won't believe how many times I've heard stories of people showing up for an all-day interview (hard to get the time to do that if you already have a job), only for half the panel to not show up that day. Those people shouldn't be part of the interview panel if they don't take it seriously. Remember, #2 above, if the candidate finishes out those who are there, and is then called back in to interview with those who couldn't be bothered to make it...they perceive that as advancing in the process, not filling out your internal hiring board process.