Starting something new is quite rare, and if it's done, it needs to integrate into a whole bunch of existing stuff one way or another; whether it's builds, deployment, auth, database, payments, UI stack, whatever - large chunks of the design space have been explored before and are pretty much set in stone unless you have a lot of political capital to spike something new, or the company is dysfunctional and doesn't standardize on anything, so that it doesn't present consistently to its users and its developers are less swappable between projects.
In a startup, you usually don't have the time or resources to play with tech and learn cool new things. Instead, you're hastily producing another simplest thing that could possibly work, using predictable tools you already know in and out. You're lucky if it's RoR or Node; you could be stuck with Go or PHP.
In an early-stage startup you work long hours, and are preoccupied with two things: how to divinate what the users actually want (usually nebulous and contradictory), and how to quickly make it work this way. You can easily lose track of what's interesting in the broader landscape, instead of enjoying new hotness as it gets released.
If you want some leisure, join a large established company, work efficiently, and you'll have plenty of paid time to fiddle with the cool stuff developed inside it, and elsewhere. Or become so advanced that a large company will task you with solving something actually novel, not amenable to off-the-shelf solutions.
What the heck? My strong sense nowadays is that most junior-mid engineers would be excited to use Go and disappointed to touch Rails.
Plus all the things @cosmodisk said on the sibling comment.
For a startup, you want wide and somewhat shallow experience. Since everything is an experiment, you want to crank out features and see what sticks.
I.e. you want a programmer that can do some UI / some app logic / some data science / some database / some infra/ops, (Not unlike a special forces person).
If you come from a big company, most roles are very specific / very deep - for example, a person works for 2 years on a file system kernel.
In addition, for your customers, the UI IS the product. Especially for the CxO level. So most of the "go/no go" decisions will be done based on the quality of the demo UI.
They needed to hire people to mentor and to help them implement better processes but at the same time being a hands on developer.
But, I have seen plenty of times where the company had an in house designer to design mockups of the UI and hire either a contractor that worked on site or a junior boot camp grad that knew $frontend_framework_of_the_week to save the heavy lifting for the senior devs/FTEs.
On one hand it seems like competent front end developers who can do “good enough” front end development and design are a dime a dozen and you can pay them peanuts. On the other hand, while I know HTML/CSS well enough to do some ugly internal site and I know JS well, I could never go from empty git repo to a well designed single page app on the front end. There is some type of mental barrier when it comes to me being a modern front end developer.
But if you give me a budget, time, and admin credentials to an AWS account, I can go from empty repo, no infrastructure to a fully baked backend solution with a full network infrastructure, database, cache, CI/CD solution easily (been there done that).
Google seems to have more “smart people” (tm) who don’t “get things done”.
Anecdotally I see a variant on this a lot. Many times I've seen programmers get hired based on pedigree. "You worked at [xyz company or on abc project] you must be an amazing programmer!"