@dzunk could you expand on using Coffeescript being a misstep?
For sure. To me it’s a microcosm of how the Javascript of yesteryear is quite different than the Javascript of today. When our Rails app was created eight years ago, Coffeescript and the Sprockets asset pipeline in general brought a lot of new, convenient, and sometimes necessary syntax and functionality. The JS ecosystem was still in its infancy - ES6 was several years away, JS package management had just become a thing (bower was released in 2012), and things we would consider essential nowadays like babel or postcss were not even conceptualized. Node.js itself was version 0.9.x.
These days, ES6+ has adopted much of the sugar that made Coffeescript so appealing in the first place, and the tooling and community around JS have grown tremendously. Many of the problems that Coffeescript was created to solve are no longer issues with a modern Javascript stack.
I think it’s fair to say the broader web development community has moved towards vanilla JS, or newer transpiled languages like TypeScript. Job applicants likely don’t know Coffeescript, and learning it in 2020 is a hard sell. There are orders of magnitude more resources, documentation, blog posts, etc. out there for Javascript vs. Coffeescript. Things like examples from package documentation or snippets from StackOverflow need to be translated to Coffeescript before they can be used or referenced.
Coffeescript is still a popular and well-maintained package, with over a million downloads a week on npm. Companies like Basecamp use it extensively, to great effect. It’s not going away anytime soon. For our app, at some point our choice to use Coffeescript went from being a time saver or force multiplier to being a maintenance burden.
I’ll try to make this post into something not completely off topic 
This is the only thing I could find in the existing Webpacker documentation about Coffeescript. Is it worth expanding or augmenting that at all?