Honestly, while that talk is cool, I don't think you should actually write lexers or parsers that way. The best way is probably the good ol' hand-written way, using something like recursive descent. It's ugly, tedious and repetitive, but if you don't want to accept any compromises, it's difficult to beat it. All of the JS parsers I've looked at do this, from V8 to Spidermonkey, to modern software like ESbuild (also written in Go and blindingly fast.)

The coroutine style of lexer is probably bound to not have such a bad slow down on larger stuff, but it depends. The amount of contention and locking introduced by adding a channel in such a hot path seems like it is probably not going to be worth it, especially if you are likely to do many parsing tasks in parallel and can simply make the boundary for parallelism further down the line.

edit: Somehow while writing this, I managed to forget that I also wrote a JS parser, albeit I never finished it. It uses a typical manually written lexer + parser, too, although it's probably pretty slow from being written stupidly. It lacks the ability to deal with a couple constructs due to ambiguity (most notably, I didn't get past the part where you parse fat arrow lambdas; it is ridiculously hard to tell them apart from other grammar elements.)

https://github.com/jchv/cleansheets / https://cleansheets.io/parser/