As I see it if you are developing something small for a client, you want to get something created ASAP get it out and forget about it. So yes, then it makes sense to use the current best framework and write code that is tightly coupled with it.
But when you start to create larger systems, you will have to think about maintaining the code, adding new features and fixing bugs. Then it is not so fun if your code depends too much on a framework and you don’t update it when new versions are released.
It is not fun googling for something and in the one result you get someone is pointing out that you are using an obsolete framework, and noticing that the post is 10 years old. (Did happen with some software I used to be developer on)
There is also an answer for that: do not build large system. Split them into largely independant parts (I think this is called silo architecture). When one of your silos get outdated, you replace it.
But when you start to create larger systems, you will have to think about maintaining the code, adding new features and fixing bugs. Then it is not so fun if your code depends too much on a framework and you don’t update it when new versions are released. It is not fun googling for something and in the one result you get someone is pointing out that you are using an obsolete framework, and noticing that the post is 10 years old. (Did happen with some software I used to be developer on)