Thanks for clarifying that. If I understand this correctly, the only way to bypass this behavior is to exec via env or any other equivalent external command?

FWIW reference to the section of the standard that mandates such behavior: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01_01

If a script interperter in hash bang is an executable and executing the
script returns ENOEXEC error, then the error applies to the interpreter
executable and we should not be interpreting script in a subshell.
Instead, return an error indicating bad interpreter.

That is, before this change, Bash attempted to interpret scripts that
declared an interpreter that exists and has executable bit set, but
built for a different platform (that is, host cannot execute it). This
is not consistent with OS implementation of hash bangs and breaks
assumptions that such scripts make (i.e. in most cases there is a reason
script has #!/bin/bash-for-aarch64 instead of #!/usr/bin/env bash). In
particular, this affects NixOS/nixpkgs when build ≠ host and some script
for the build platform accidentally leaks to the host configuration.
See also https://github.com/NixOS/nix/pull/10291#issuecomment-2016737437