He didn't actually describe what those lines do, which is amusing since there is actually a comment that explains them right above them in the code they came from.
I thought it was a fun example because I know that an adequate programmer can, in fact, understand it purely from the code— since I was given an algebraic simplification of that code (taking advantage of the fact that in the calling enviroment case it's never used with val==0) by a random OSS contributor, and I think that was even before it had a comment explaining what it was doing.
A detailed description of this code ends up being an opaque transliteration which people will convert back to $language incorrectly (noting that kokjo actually did have trouble figuring out what computation it was performing and doubted his understanding of the mere behavior). While, a high level description "This is (val>>(l-16)), but guaranteed to round up, even if adding a bias before the shift would cause overflow (e.g., for 0xFFFFxxxx)." would almost certainly be implemented incorrectly, as you can see it's a bit tricky and joe-random-programmer doesn't generally know how to make fixed point division round up even before you worry about overflow. (How many people know about the truncation vs floor behavior of >> and / operators, and that they're not the same in, e.g. C and python or how you convert one to another, or would even realize that they had to take special care— even if the spec called it out?)
I'm sure a sufficiently deft drafter could write a spec that handles this... but this is two lines. Getting exact behavior when you need to worry about things like overflow and correct performance over the entire range of a machine number is simply hard and a lot of programmers are not mentally prepared for it. Writing spec text which doesn't create hazards can be tricky.