Which require that data take a round trip between the R process and the database. It's not uncommon for these jobs to spend more time in the read/write step than doing meaningful work, and why I prefer dbt when possible to keep transformations as close to the data as possible.

Sadly, the company closed this June, and even the website is already down.

ETA: Seems it isn't. https://www.deepchannel.com/ That what you meant?

In that sense it should only be used for last mile data transformations. Not for wrangling raw data into neat tables.

Edit: I am also curious why you consider SQL to be inferior for the latter?

After that step the data is a lot more uniform, so then it's easy to use SQL.

A lot of these discussions are basically "can we please just use the language/tooling we know", and sometimes the answer's yes! A lot of people breathe a big sigh of relief when they discover you can use like, Spark through Python and what-not. Regardless of whether or not it's a good idea or good use of resources, this space is advancing because the market demands it. But like, I don't think you're ever gonna use dbt with not-SQL; it's all in on SQL. Feels like maybe it was the wrong fit for your team.

I should say I'm not sure if your coworker was an SQL person so dunno if this directly applies. Just saying what my experience has been.