The major benefit of this approach is that you can avoid a database lookup when you have a valid JWT available. Only in cases where it's missing or expired would you need to hit the database for a refresh token.
This might not matter for trivial apps, but for very high-concurrency web apps this will matter a lot.
Yes, that's why long time ago we figured out how to store those in some extremely fast memory store like memcached or redis. I hope people that work at scale where it's not a viable option don't need to read such blog posts to set this up.
To store 1M sessions, let's say each is 2 KB, you going to need 2GB. Somewhere around 15K session look ups per second will saturate the server (+/- 5K ops/s depending on the CPU) . If you want more sessions - use more RAM, if you want more ops/s - use more servers (cache cluster).
Another reason to JWT - cross-region authentication (replicating giant session store across the globe isn't a viable option)
This might not matter for trivial apps, but for very high-concurrency web apps this will matter a lot.