IT IS a mess, but I never saw json inside a cookie. For json I use local storage or indexeddb.
If you only ever need the stored data on the client, localStorage is your pick. If you need to pass it back to the server with each request, cookies.
It would never occur to me to put something more than a simple token in a cookie. A username, and email address, some opaque thing.
The idea of trying to use it for arbitrary strings just seems weird to my intuition, but I don’t really know why. Maybe just because when I was learning about them long ago I don’t remember seeing that in any of the examples.
Csrf is no problem as the data from service worker is only active on the site itself. If you speak about csrf with a website where you can't trust js, you're site is broken as xhr/fetch use the same httponly cookies and is affected as well.
I think the distrust of js is a personal issue.
You need server verification for data that's important. Native programs can be changed with over programs or hex editor.
The talk was about data that is stored into cookies as json and csrf. (Cookies can be changed with devtools or extension)
Csrf is always an attack from third party against the user, if the user extract the data itself that's no csrf problem.
Because of this I thought you distrust js that can get attacked from third party, but yes js is as easy to change like .net or java programs.
I'm not a fan for jwt and it used more often than it should, but sometimes it makes sense.
(Seriously though, someone trying to implement breadcrumbs fe-only)