When you wrap an autocmd inside an augroup and empty the latter with autocmd!, you prevent the exact same autocmd to be installed several times in case you source your vimrc more than once. If you want to check this out, here is a way; add the following code inside your vimrc:

autocmd BufWritePre * call SomeFunction()
function! SomeFunction()
    echom "Writing buffer!"
endfunction

Restart Vim, and open a file. Write the buffer even if you didn't make any changes (:w), then type :messages. You should see the message "Writing buffer!" only once. Now resource your vimrc (:source $MYVIMRC), rewrite the buffer, and read the logged messages again (:messages).
This time "Writing buffer!" should appear twice. If you repeat the process, you should see that the more you resource your vimrc, the more there are repeated logged messages when you write a buffer, meaning SomeFunction() is called more and more.

To solve this issue you can use an augroup and autocmd!:

augroup somefunction
    autocmd!
    autocmd BufWritePre * call SomeFunction()
augroup END

This time, whenever you write a buffer, there's only one additional message, meaning the function is called only once, whatever the number of times the event BufWritePre was detected (i.e. number of times you wrote a buffer).

Now, replace the event BufWritePre with FileType c and the command call SomeFunction() with autocmd BufWritePre * call SomeFunction():

augroup somefunction
    autocmd!
    autocmd FileType c autocmd BufWritePre * call SomeFunction()
augroup END

Then, restart Vim, edit a .c file, write the buffer and look at the output of :messages. "Writing buffer!" should appear only once. So far so good.
But then edit a second .c file, write the buffer and look at your messages. This time "Writing buffer!" has been logged twice. If you repeat the process, you should see that the more you edit .c files, the more there are logged messages when you write a buffer, meaning SomeFunction() is again called more and more even with the augroup and initial autocmd!.
Why? Because they protect you from duplicating an autocmd when the "event" (it's not technically a Vim event, it's just for the sake of making a comparison, hence the quotes) * I source my vimrc * repeats itself. But it does NOT protect you when the event FileType c repeats itself. Usually you don't give a damn about an event repeating itself because you call a basic command (like a simple function call), and a basic command can't be piled up. For example, Vim will not remember you already called SomeFunction() several times. However, the installation of a nested autocmd can pile up as Vim does remember that you already installed one. So when your basic command becomes the installation of another autocmd (meaning you're using a nested autocmd), then every time the event FileType c repeats itself the nested autocmd is duplicated.

In the link I gave you, they had a discussion in the comments about that, and seem to have come to the conclusion that the nested autocmd should empty the augroup in case the FileType c event repeats itself.

As a side note, personally, I think you're right thinking that it's unnecessary. But not for the reason you thought. I may be wrong, but I think it's unnecessary because of the special pattern <buffer>. The previous autocmd was still wrong because as soon as you would open a .c file, Vim would install the nested autocmd for any buffer (because of the * pattern). This means that afterwards SomeFunction() would be called for any buffer even if the filetype is not C.

To fix this other problem you have to replace the pattern * with the argument <buffer> which should limit the scope of the autocmd to the current buffer. So the correct autocmd would be:

augroup somefunction
    autocmd!
    autocmd FileType c autocmd BufWritePre <buffer> call SomeFunction()
augroup END

If you try this code you should see that <buffer> not only fixed the problem of the scope of the autocmd, but also the problem of the duplication of the autocmd. Because, whenever you write a .c file, there's only one "Writing Buffer!" added in the output of :messages even if the event FileType c was repeated after opening several .c files.

So I think that in your particular case, the following code should be enough:

augroup LongLines
    autocmd!
    autocmd FileType c,cpp,python,sh autocmd BufEnter,BufWritePost <buffer> call HlLongLines()
augroup END

But again, on the linked I gave you, they don't seem to agree, so I don't know, maybe I misunderstood something. If you want, you can make some tests and see for yourself or open a topic somewhere to ask the question.

Honestly, I find the second syntax easier to understand and to predict, so if I were you I would use it instead:

augroup LongLines
    autocmd!
    autocmd BufEnter,BufWritePost * if count(['c', 'cpp', 'python', 'sh'], &filetype) | call HlLongLines() | endif
augroup END

Or a slightly different variant:

augroup LongLines autocmd! autocmd BufEnter,BufWritePost * if index(['c', 'cpp', 'python', 'sh'], &filetype) >= 0 | call HlLongLines() | endif augroup END

By the way, I think you're right, in your particular case, the event BufEnter is probably better than BufRead, because with the latter your function would be called only when a buffer would be loaded in memory, whereas with the former it's called whenever you display it in a window.