I try every new tool and can never say afterwards whether any of them was better - how do you decide what is worth moving to?

Then count the other side, which people systematically ignore: the cost of moving is much larger than the evening it takes to try.

What a switch actually costs:

Migrating what exists. Usually the largest and always underestimated.

Relearning. You are fast in the old thing and will be slow for weeks.

Everything downstream. Scripts, integrations, documentation, whatever your team knows.

Being an early adopter. Fewer answers when you get stuck, more rough edges, and the chance it is abandoned.

Against that, the benefit has to be substantial rather than pleasant. My rough test: is this at least twice as good at something I do often, or does it remove a problem I actually have? Marginally nicer is not worth a migration, however good the demo felt.

The corollary is that the best time to adopt something new is when you are starting something new. The migration cost is near zero, and the risk is contained. Trying a new tool on a fresh project and leaving the existing ones alone gets you most of the learning for a fraction of the cost, and it is what the productive constant-switchers are usually doing rather than migrating everything every month.

The problem is the demo project. Everything is pleasant on a fresh empty project, because the demo was designed by people who wanted it to be, and because none of your actual problems exist there.

So the single change that fixes most of this: evaluate on a real task from your real work. A small one, ideally something slightly awkward that you have already done the old way so you have a comparison.

What that exposes and a demo cannot:

How it behaves on your existing mess rather than on a clean slate.

What happens when something goes wrong, which is where most tools reveal themselves. The error messages and the debugging story are more important than the happy path and are never in the demo.

The second and third hour, when the novelty is gone and you are just working.

Whether it fits everything else you use, which is usually the actual constraint.

Write down before you start what would make you switch: specifically, one or two things. Then you have a criterion rather than a feeling, and if the answer is no you can move on cleanly instead of half-adopting.

Half-adopting is the failure mode to watch for: two of everything is worse than either one.

Waiting two releases costs almost nothing and removes the ones that were interesting rather than good.

Ending up with two of everything is the actual outcome of most enthusiastic evenings.

The other lever is timing, and waiting is underrated.

Very little is worse in six months. If a tool is genuinely good it will still be there, with better documentation, fewer bugs, more answers to your questions when you get stuck, and a clearer picture of whether it is maintained. If it is not, you will have saved yourself a migration into something abandoned.

What I look for before adopting something into real work:

A second major release, which tells you they can handle their own breaking changes.

Somebody other than the author using it in production, and writing about the bad parts.

An honest limitations section in the documentation. Its absence is a genuine warning sign.

A migration path out, which nobody checks and everybody eventually needs.

On the personality question at the end of your post: partly, and the useful reframe is that following and adopting are different activities. Reading about new things is cheap, keeps you aware, and costs an hour. Adopting is expensive. The people who look productive while switching constantly are usually following widely and adopting rarely, and the ones who look productive ignoring everything have usually just made that trade explicit.

Keep reading. Adopt on a criterion.