No, the binary is fat (contains several build targets in an app wrapper) and the only code that can execute does. I would argue this is the correct behavior for open, but I suppose reasonable people could expect a strict interpretation and would rather get an error than an app that could open, not opening.
You can test this out empirically by specifying each architecture sequentially and running sudo sample PID 1 500|head -12 and verifying the Path, Identifier, Version and Code Type is native or (translated) where PID is the process ID of the app that you open.
On Apple silicon, –arch i386 runs on native ARM, –arch x86_64 is translated Intel code.
Analysis of sampling Safari (pid 53256) every 500 milliseconds
Process: Safari [53256]
Path: /System/Volumes/Preboot/Cryptexes/App/System/Applications/Safari.app/Contents/MacOS/Safari
Load Address: 0x102800000
Identifier: com.apple.Safari
Version: 18.1.1 (20619.2.8.11.12)
Build Info: Safari-7619002008011012~2
Code Type: ARM64E
Platform: macOS
Parent Process: launchd [1]
Analysis of sampling Safari (pid 53350) every 500 milliseconds
Process: Safari [53350]
Path: /System/Volumes/Preboot/Cryptexes/App/System/Applications/Safari.app/Contents/MacOS/Safari
Load Address: 0x1008ae000
Identifier: com.apple.Safari
Version: 18.1.1 (20619.2.8.11.12)
Build Info: Safari-7619002008011012~2
Code Type: X86-64 (translated)
Platform: macOS
Parent Process: launchd [1]
