As with most things, it depends.
For some applications, it's not likely you'll be running a migration against a far-future version of the codebase, so it's not necessarily worth the time to make migrations runnable against any conceivable future version of the codebase. Instead, it's more convenient to write migrations that are intended to be run against the current codebase.
On the other hand, if you have a lot of developers and a lot of code churn, then it's likely that your migration will run in a slighty-future version of the codebase where someone may have changed something you depend on in your migration. In this case, it's helpful to insulate yourself against these kinds of potential changes.
If the team is small, consider going with the convenient option.
If the team is large, consider going with the more time-consuming option as a way to mitigate risk.
Finally, for things like Rails engines where the migrations are only run when your consumers upgrade your engine, it's likely that migrations are run in a future unknown codebase, so you definitely have to build the migrations in a way that does not depend on the current codebase. https://github.com/spree/spree is a good example of this.