When evaluating senior level and up developers, I look for a mandatory quality -- opinionated but open.

You need to be opinionated in choosing your technology, and often this falls down to "I am most comfortable with and have the most experience with X". In the current technology ecosystem, there are thousands of competing language/framework/database/ops choices. Many will have overlapping pros/cons, and you may never reach the corner cases that distinguish them. When that is the case, experience will give you a gut feeling, and you should stick with this feeling. Additionally, you should usually give preference to the tools you have used before as that will reduce implementation time and trouble, as well as increase efficiency. That's being opinionated.

However, you must always be able to back your reasoning with facts. "X is good for this project because." If you can't do that, then your opinion is uninformed and not useful. Additionally, you must always be open to there being a Y that is categorically better than X for the task. And if someone brings that to your attention, and has a good rationale, and the cost and time of implementing Y is within the projects budgets, you must be open to using Y. That's being open.

So when someone questions why I use X, I do not hesitate to say it's because I prefer X, and I think X is good for this project because of factors A, B, and C. If someone says "Y would be better than X here", I'll listen to their justification and weigh the cost of learning Y. If it's convincing, I'll give Y a shot (after doing my due diligence). Having a large toolbox at your disposal is invaluable, but there's simply too many tools in tech now to be able to learn them all. Pick ones you like using (or at least are the least hateful of the choices you have -- Ansible, looking at you), and be open to learning something new if there's a very compelling reason to do so.

-Hey man, did you hear about the new project? The client will give us the freedom to choose whichever tech we want! He just want it to look "cool". Isn't that great?! Which one will you choose?

-It depends. Probably X.

-WHAAAAT?! Didn't you hear about Y, it's awesome! People are loving it. It's new and modern and the community behind it is growing every day. Let's build it with Y.

-Calm your horses, Stevie! Do you really want to jump in the water, without even knowing how deep it is? Think about it, do you want to maintain a project, build with something you and I don't even know that well. Do you want to loose your mind on fixing "that" bug or implementing "that" feature, just because we chose Y "`cus the cool kids are using it". What about extensibility, maintainability, scalability? Let's do a research tomorrow morning and find which one works best. We may find Y is the right tool after all.

-Man, you know you broke my dreams, right?

-I know, Stevie, I know. The next drink is on me!

Familiarity is always something I take into account when choosing tech for a new project, but I also balance that with other factors like speed of development, is this a very long-term project or something that needs to be done yesterday, how mature the tech is, etc

If it needs to be done "yesterday", then choosing something you're not familiar with is almost setting yourself up for failure, I've seen many projects fail or go waaaaay over budget simply because developers weren't familiar with the stack and in cases where it was a complicated stack, very buggy code emerged. On the flipside, I've seen many more projects succeed where developers were familiar with the stack, but there were still failures in some projects due to other problems - long story short, familiarity with a tech stack will increase your probability of successfully completing a project.

If it's a R&D type of project or something which doesn't really have an immediate deadline, having the flexibility to play with new tech is sometimes fun, but you will often churn through many months of trial and error before you get to a point where you fully grasp the technology and are able to start building useful stuff with it.

I've also been burned in the past by tech that's not yet fully mature - often you'd get stuck and nobody would be able to help you. Many years ago when GWT was the new kid on the block, you would post on StackOverflow and not get an answer at all, post something about jQuery and by the time you hit submit and refresh, you already had two answers. So something I also take into account is maturity, how many well-maintained libraries are available, what kind of support are available for it - do you have an army of people waiting to respond to your questions or are you the lone ranger battling through language / framework quirks all by yourself.

Also on maturity, is the language / framework about to undergo major changes that are not backwards compatible that will break your system? If this happens often, I would often disregard the framework / language as a viable option.

Here is a database of application development technologies and their benefits (reasons for choosing them). It's very detailed and you can use it to see lists of the trade-offs between any comparable pair of technologies in the database. It also accepts corrections. So if you see anything that looks wrong, feel free to submit one.