Fun facts: those are commonly known as "vbytes." They are the slowest kind of variable width integer encoding. The simplest (naive, and generally considered "wrong") implementations of variable-width-by-continuation-bits uses 10 bytes maximum. A proper implementation uses 9 bytes maximum.

There's actually no reason to ever use 10 bytes in this encoding. If you use 10 bytes, that means your last byte only holds one bit of actual user data. That's not very cool. But, your next-to-last byte holds seven bits of user data and one bit of metadata. We can easily say "if we're at the next to last byte, don't use metadata, just use all the bits we need." All you have to do is say "if we are currently at 9 bytes, don't use a 10th byte, just use this 9th byte directly." bam. Your 9th byte now has 8 bits of user data and you don't roll over a useless 10th byte with one bit of data.

The "slide all continuation bits into the first byte" sounds like a trick, but it's really using a TLV encoding where the first byte just holds a number between 1 and 8, so the entire integer+metadata is now [1 type byte][1 to 8 user data] = 2 to 9 bytes total. Using this scheme also kills any "1 byte, standalone, variable width integer" capability (unless you're storing partial values in the first T/L byte, but then that limits you to a much lower max value for one byte).