I understand what you are saying, but not why you think it's a bug.
Once again, the call to after-change-functions in this scenario is
done not from insert-file-contents, but from the function that decodes
the text read from the file.  That function runs in a temporary
buffer, which has no associated file name.

Because the docstring of after-change-functions says the hooks are called with the current buffer, and the current buffer at the time insert-file-contents is called, is the file buffer, not the code conversion buffer. The message printed out also indicated that the current buffer at the time the after-change-functions lambda is called is indeed the file buffer, not the code conversion buffer. The file buffer's buffer-file-name should not be set to nil by insert-file-contents or any function it calls. As far as I know, only `insert-file-contents` exhibits this undocumented behavior for any functions that change buffer contents.

The guarantee of after-change-functions being called with the current buffer isn't very useful if crucial variables of the current buffer such as the buffer file name cannot also be guaranteed to remain the same. This use case is illustrated by the tickets I linked to in my original report. There exist many file formatter packages that replace the content of the current buffer with a temporary file with the formatted file content inside a before-save-hook due to slowness of replace-buffer-content. When these packages are used in combination with lsp-mode, which has a function added to after-change-functions that needs access to the current buffer's file name in order to synchronize the document between the editor and the language server.