It depends on the level of scrutiny. It doesn't seem unreasonable. We review a lot more code per hour (usually C-like code though) but then we're not supposed to lock someone up for murder, we just find basic things like memory corruption. Don't even need to get into the business logic to find bugs that totally break the application, let alone all of it.

When writing Python (I don't have stats about reading), a 1.0 version of a small project took me 1.5 hours and consisted of 183 lines of code, so 2.2 lines per minute. That's much faster than this, but 183 lines is also a ton less complex than understanding the entirety of 180k lines and properly assessing whether it does exactly and only what it's supposed to.

10 lines per hour is probably taken as a lower bound to prove a point, especially because they argue about checking the whole thing (large parts can probably be skipped), but as a standalone statistic I would say it's probably within an order of magnitude from the true value. And for software time estimates that would be an amazing feat :p

If it means what I think it means - understanding the code - sometimes it takes days to understand just one line of code. Document digging, googling, asking around, fiddling with test cases, reading production log etc.

have you ever seen MATLAB code?

Yes, You also dont read programs like a book, You generally follow the methods being used, Reading line to line would be like reading a a book with all its pages re arranged.

Both 0.1 lines an hour and 1000 lines per hour would be equally wrong. That isn't how people would review that sort of code. They would test it and then thoroughly examine any areas of concern that crop up.

I've run into 300-line programs that have taken me a month to figure out because the math was hard and I've run into 100,000 line programs that have taken me a few hours to tear apart.