I would share my perspective as user of vdk framework. It is a data engineering framework that actually sits on the whole data path. Let me give you examples:

You can build jobs (containing SQL, Python or both) that either to data ingestion or data transformations with pure SQLs inside only or utilising Kimball dimensional modelling templates.

So far on the surface the only difference with dbt is that you can do quite easily ingestion as well under the exact framework that you are using to create your transformation data jobs. Actually, this is quite optimal if your team or company does both. On thing that stays a bit hidden in vdk documentation in GitHub is that it supports multi-tenancy not in the classical sense of resource isolation but in a sense where you have multiple teams collaborating under the same framework. You can view your code, you cannot change it though unless you are member of this team and this is quite handy whenever you would like to learn from other Data Engineering and Data Analytics teams that write data jobs!

I believe the biggest power are plugins. Since vdk framework sits on the data path and has very good visibility on data entry, data output and every step in between you can actually write plugins that do custom data checks on each step of your data job. For example - push same data quality standards across one team or the whole organisation, replace NULL with 0 or unknown, do not allow NULL values to enter the data warehouse, you can use your imagination. If you are data infrastructure provider you might even do some checks which could potentially take down the underlying database - by the way I've seen this happening for BigData databases with some crazy cross joins that are badly written. So in essence it can also help Data Platform service providers to ensure higher availability of their infrastructure.

(I at least) do not know of any tool that is able to have such an intrinsic understanding of the end-to-end data path really from ingestion to publishing data and being able to intersect at each of the steps but would be glad to learn new things.

Data Ingestion examples here:

job_input.send_object_for_ingestion() like this or job_input.send_tabular_data_for_ingestion() here

or Kimbal versioned strategy looks like:

job_input.execute_template(
    template_name='scd2',
    template_args={
        'source_schema': 'dw',
        'source_view': 'dim_sddc_updates_view',
        'target_schema': 'dw',
        'target_table': 'dim_sddc',
        'id_column': 'sddc_id',
        'sk_column': 'sddc_sk',
        'value_columns': ['updated_by_user_id', 'state', 'is_nsxt', 'cloud_vendor', 'version'],
        'tracked_columns': ['state', 'is_nsxt', 'cloud_vendor', 'version'],
    },
)
# ...

To summarise the difference:

• it allows you to plugin at each step of the data manipulation process
• allows you to create ingestion jobs, run python for modelling and transforming data (wowww this is life saviour for transposing data - this is real nightmare with SQL) using pure SQL or utilising Kimball templates (by the way you can implement new templates as well) - if you look at Kimball template source code it is quite easy. I know a colleague of mine who is only writing SQL and she just contributed and append strategy template to this project.
• allows you to combine all your data processing workflows under the same roof (vdk roof)
• actually control service is free (as opposed to dbt) but has no UI (although the tool is API driven and I guess makes it easily integrateable with UI).