In their previous tutorial [1] their encoding settings show that they're targeting roughly 128 kb/s VBR, which is what YouTube AACs typically are, so that doesn't explain it. AAC (and Opus for that matter, which YouTube also often has) are superior formats, and lossy encoding should only happen once if possible- so this honestly makes me cringe a bit. In this case the (probably already lossy) source audio is lossily converted by YouTube and then again by ffmpeg/LAME with rather low bitrates at each step. A lot of quality is lost along the way.
Support for Opus is unfortunately still somewhat sparse, but AAC support is essentially universal on modern devicese. So I can't think of any reason to favor this approach over:
youtube-dl -f bestaudio[ext=m4a] "$URL"
Even YouTube's 128 kb/s copies won't satisfy audiophiles.
I can definitely understand you cringing about the re-encoding, but I just wanted to point out that the reason that we took this approach was simply to give a semi-plausible real-world example of how tools like aws-serverless-express [1] and Exodus [2] can be used to build useful APIs with AWS Lambda [3] and AWS Gateway [4]. These articles are primarily meant to be educational tutorials that people can use as a reference when writing and deploying their own APIs. The whole "converting to MP3" thing is just an easily understandable premise which lays out a clear goal for the tutorials to build upon.
Support for Opus is unfortunately still somewhat sparse, but AAC support is essentially universal on modern devicese. So I can't think of any reason to favor this approach over:
Even YouTube's 128 kb/s copies won't satisfy audiophiles.[1] https://intoli.com/blog/transcoding-on-aws-lambda/