The assumption is that the packet is something like header + file (I don't know if header is the right terminology). You don't know how many bytes the header is, so you increment the header length until the remaining bytes are recognized as a file.

AFAIK often the file type signature is in the beginning of the data, however a proprietary elevator music solution could add their custom headers to the beginning of the stream, or, he might have captured data midstream

It's a way to find the start of the file header when you don't know the original offset. You have to have an idea about the target header format, and in this article the author was looking for an audio stream because each packet ended with LAME3.91UUUUUUU which is an mp3 audio encoder with a funny acronym. You use n+1 so each at each packet you're looking at a different part of the packet.

The idea is that the file within the byte stream does not have a clear start marker (due to the unknown length of the customer headers), so you bruteforce trying to find the file.