Yes. I've used similar things from this episode on some projects. My breadcrumbs were a bit different so the markup changed a bit, but the overall concept is the same. I've used similar approaches on SEO data as well (page titles and descriptions).

Really cool! Another idea for your gem, allow a block with the listing of columns. Kind of like a small DSL for the ordering and selection of columns. 

I've been working on a project which takes the ideas of the Datatables and is basically a full rewrite; allowing pagination, individual column searching, column selection and ordering, saving custom reports and setting defaults, etc. It's a pretty large library so far, but not ready to share with the world. 

On an existing established application, you would be adding extra dependencies for a micro framework. While Webpack would have long running benefits in the application, I wouldn't necessarily add it into one just for this. If I was tasked with refactoring the app and clean up a bunch of javascript files, vendor assets, etc. then I would consider adding it in.

It is mostly the extra dependencies needed; javascript runtime (NodeJS), yarn, etc. In my apps, I usually add mini_racer or the_ruby_racer to the Gemfile for handling the JS Runtime so I don't have to worry about machine dependencies. However, with Webpack, you would need it on there. Again, it's not a huge deal, but I would want a reason to add it in. Since their documentation does have a way to support Stimulus without a build system, this would be the route I would go with unless I was doing some other major kind of refactor where the introduction of a build system would benefit. https://github.com/stimulusjs/stimulus/blob/master/INSTALLING.md#using-without-a-build-system

Personally, I would probably use deliver_now. The background job is already asynchronous so there isn't much point to loop back to another job. However, if I were sending many emails within a background job, I would use deliver_later.