Funny you mention this, as I've written quite a bit of Python code that works just like this, typically in the form of an evaluator for some random proprietary language I've parsed into an AST in the form of a Python list or tuple.

Before you could assume...null pointer derefs will be trapped by the OS

Before when?

  Microsoft(R) MS-DOS(R) Version 6.22
               (C)Copyright Microsoft Corp 1981-1994.
  
  C:\TMP>type foo.c
  void main() {
      long q = 0;
      q = 0/q;
  }
  
  C:\TMP>cl /Od foo.c
  Microsoft (R) Optimizing Compiler Version 5.10
  Copyright (C) Microsoft Corp 1984, 1985, 1986, 1987, 1988. All rights reserved.
  
  [...]
  
  C:\TMP>foo

  run-time error R6003
  - integer divide by 0
  
  C:\TMP>type bar.c
  void main() {
      long far *p = 0;
      long q = 0;
      *p = 0;
      q = 0/q;
  }
  
  C:\TMP>cl /Od bar.c

  [...]

  C:\TMP>bar

I was, but my application was less fun: porting Perl code from Windows NT to MS-DOS to integrate with software that required direct hardware access to a particular model of SCSI card.

Worked great, and saved a bunch of time vs writing a VDD to enable direct hardware access from NTVDM or a miniport driver from scratch.

IIRC, the underlying problem was that none of the NT drivers for any of the cards we'd tested were able to reliably allocate enough sufficiently contiguous memory to read tapes with unusually large (multi-megabyte) block sizes.

To be fair, I've seen definitions of AI so broad that they'd probably include the root finder on my HP-15C.

Not so cheap if your hardware decoder only supports 8-bit color, which is a common limitation of H.264 decoders in particular.