Looking through the migration guide, I'm still uneasy about where configs for "ops" are being defined.. why not define config for the op where the op is defined?

@op(config_schema={"param": str},
    config={"param":"some_value"})
def do_something(_):

you mean define a default value for the schema? You can set a default for the op where the op is defined:

@op(config_schema=Field(str, default_value="foo")...)

The default_value on schema makes a lot of sense. Curious though what is the recommended practice for setting default values? Most of the time the docs refer to a huge config block on the job/pipeline. Is there a difference between setting the default on the schema vs through the config block of the job? And what are we gaining by doing it via job's config block?

In terms of functionality they're equivalent, so neither is "recommended" over the other per se. Defining the run config in a big blob is arguably more convenient because it becomes your single source of truth for viewing the default. It also allows you to define different defaults for different jobs. However, if you know that the default for an op will stay the same across jobs, then it might make sense to define the default at the op instead. Hopefully this helps weigh tradeoffs

Would it be possible to define a schema default_value and a job config block value for param? If so, which takes precedence? (I assume job's config block param value would override the schema default?)

that's correct, the job would override