Using services/records etc in migrations
Are there technical reasons for this recommendation, or is it something you'd just rather not support?


It's more along the lines of it's something you're not going to want to support.

The problem is that things like services and records change over time.  Methods get renamed/deleted, attributes change, parameters change, etc.

By using them in a migration you're assuming that the methods you're calling and the attributes you're using are going to be there for the rest of time and that's not necessarily going to be true.

A year from now if someone tries to run that migration, there's a chance those services and records are going to look very different and the migration is going to fail because it was written for what the service/record looked like a year ago.

You're much better off thinking of migrations as little self-contained applications with as few dependencies on external Craft classes as possible.