The majority are simply going to follow popular opinion regardless of the merits, and developer efficiency is often not that important. I also think the efficiency gains are bigger for smaller and inexperienced teams.
Also, people are getting used to app-like experiences and designers are designing for it. Building an app-like experience is more natural as a Single Page Application, which basically means taking on the modern frontend stack. There are places that push against this, but to do so requires buy-in to the engineering side over product and design. Even then, the engineering side has to be knowledgeable enough to not follow popular opinion and come to the determination that Laravel/Rails/Django is actually the right tool, which isn't always the case.
True liberation is non-attachment. By attaching yourself to doing something that you love, you may be setting yourself up for disappointment.
Is this really what I love? Is my solution actually helping anyone? Will I have to make compromises to better monetize my solution? I've been working on this project for a year and don't feel like I've made a meaningful innovation.
Some people go down this path and everything works out well but not everyone.
I've never been involved in the game industry but it sounds believable to me. It's not a given that having a CS degree means a person can code, which is one of the reasons we code test in interviews. And I imagine the game industry requires higher coding ability. There are also people that want to be in the game industry no matter what. They would rather be a tester in games than a programmer outside it.
I think there are ways to do this correctly but it has to be more static pages with JS enhancement and/or making certain sections standalone "single page apps". It sounds like you're halfway in-between and that leads to the sorts of issues you're talking about. Being halfway in-between does mean that you're also halfway to an SPA, so maybe just commit fully to that direction?
Personally, I find webpacker to be straightforward and not that magical relative to the asset pipeline.
I think a core problem is that the incentives are to give a quick diagnosis and prescription, and if that diagnosis is wrong, move on to the next diagnosis / prescription, repeat. This is in contrast to my experience with a functional doctor, who laid out a logical plan, testing to verify hypotheses, and only after all the pieces fit together, decided on a treatment strategy.
Of course, for the majority of cases, the mainstream approach works well or well enough, but it's definitely frustrating when you fall outside of it. I think some people don't even know they're falling outside of it (e.g. long-term gastrointestinal problems), as in they've given up figuring out the root cause and have learnt to deal with their symptoms. I think the number is non-trivial (1%+?), but I can't think of any way to prove that.
I do think it's important to think critically and not just do something for the sake of doing it. Testing well is not easy to get right. If your tests are constantly changing, then the tests are probably too coupled with the implementation. However, I think it's safe to say that the user wants some level of consistency in the product. If your tests captured what needs to stay consistent, you should theoretically see less churn in the test code.
There are other ways to get a stable system. It seems like the code that you're working on doesn't see much code churn and you have a good understanding of the system. This is definitely a situation where I see testing not being as valuable.
I think one of the big reasons testing is considered a good practice is we're relying more on dependencies that need to be updated somewhat frequently, and semver is not taken as seriously, especially in certain web ecosystems. There's a decent chance you don't work in such an ecosystem where it's not an issue, but that's the biggest reason for me to advocate for testing.
The other big reason is that it's easier to make changes in a codebase that you aren't familiar with when tests are available. This is especially true with software that may have non-obvious corner cases.
My guess for the small companies that don't hire is that it's the incentives. If my outcomes as the hiring person are that a bad hire is a large negative, a no hire is a very slight negative, and a good hire is a slight positive (possibly even neutral), I'm going to prefer no hire most of the time. I believe this is a fairly common decision matrix.
For example:
bad hire lowers managements' opinion of my performance and can be costly to team morale, especially if company culture makes firing difficult
no hire can be blamed on lack of qualified developers rather than a competency issue
good hire is nice, but if current development team can push back on workload, that benefits the company much more than the development team
What was the placement rate for the candidates that you put forward? Based on your statements, I would expect this number to be very high, but from my understanding of the industry, including recruitment companies that do technical assessments, I would be surprised if it was that high.
I'm not sure how to reconcile a recruiting company well-known for doing rigorous technical screening having a 40% placement rate, most candidates being a clear yes or a clear no, the hiring process being completely fine, and the hiring process not producing many false negatives.
A 40% placement rate implies triplebyte has the hiring bar lower than companies want it to be. Ie, even with rigorous screening, they have a high false positive rate. (Well, that assumes candidates are totally ordered by desirability, which is not at all the case).
Also, people are getting used to app-like experiences and designers are designing for it. Building an app-like experience is more natural as a Single Page Application, which basically means taking on the modern frontend stack. There are places that push against this, but to do so requires buy-in to the engineering side over product and design. Even then, the engineering side has to be knowledgeable enough to not follow popular opinion and come to the determination that Laravel/Rails/Django is actually the right tool, which isn't always the case.