This seems like it could be a great series. I would be more likely to read it if the code the JIT is built for wasn't BF. It's just too tedious to follow along by copying everything into another interpreter to make it readable.
Like the post says, there are plenty of others on the web about implementing interpreters or compilers for more useful languages, and, even if it's just Scheme, those tend to spend nearly all their time on the parser. I really like this series because it skips the parsing part to get to the most interesting and relevant topic: how actual language runtimes are implemented.
Well, why not just make yet another one for one of those more useful languages, but not fall under the same trap of spending too much time on the parser?
Because then you're increasing the cognitive overhead for the reader and the time commitment overhead for the writer.
But yeah, if the author wanted to make a part 3 it might be interesting to see his implementation for something like (a simplified subset of) Java bytecode.
Yes, sorry, I mean to make it human-readable, I always copy BF to https://copy.sh/brainfuck/ so I can check whether the output is correct. '12345' is a lot easier to read than +++++++- ++++++-+ ++++++-- +++++-++ +++++-+- or whatever.
I agree that the language itself is very likeable for the reasons you stated, but I'm partial to things that I can easily check. It's called Brainfuck for a reason. ;)