Not really. The HLS demuxer usually provides all streams of an HLS source, video, audio and subtitles, and that's the way it is meant to work. Even with that stream in question it does so, and a transcode output creates a file with both, video and audio (you can't hear the audio, though, likely due to the timestamp errors).

The code you have shown is no more than a workaround and not the way how it's supposed to work.

I can't tell whether the HLS source is malformed in some way or whether it's rather an issue in ffmpeg. Both ways are possible, but due to the fact that it's the first time seeing this, I'd rather suspect the HLS source - if not invalid then probably at least unusual in some way.