[I'm posting this as an attempt at general education. No personal attacks or hostility intended]

> If you tell someone that a device does NAT, but not routing, they're going to expect the packets to go in one side and come out the other side, right?

Only if they haven't read RFC 2883 (or similar documentation). I would describe a "device that does NAT but not routing" as highly unusual, possibly purpose-built to update an older network or workaround some kind of compatibility/interoperability problem. Such a device would probably be a custom iptables (or equiv) configuration on a standard linux (or equiv) box, not a branded "router".

However, another interpretation is that the terms "NAT" and "routing" are being used in the colloquial sense that usually only refers to NAT and routing to refer to something roughly similar to the home devices that sit between the LAN and a {cable,ADSL} modem. In that sense, a device with two cables attached might not appear to "routing" anything. In previous posts, I'm using the technical definition of NAT as defined by RFC 2883, not this broader colloquial definition.

By the technical definition, the device is "routing packets"! NAT is defined as something that performs "transparent routing" between address realms. From RFC 2883: [1]

    2.2. Transparent routing

       The term "transparent routing" is used throughout the document to
       identify the routing functionality that a NAT device provides.  This
       is different from the routing functionality provided by a traditional
       router device in that a traditional router routes packets within a
       single address realm.

       Transparent routing refers to routing a datagram between disparate
       address realms, by modifying address contents in the IP header to be
       valid in the address realm into which the datagram is routed.

NAT transparently[2] "routes" between address realms[3], which are defined as:

   2.1. Address realm or realm

   An address realm is a network domain in which the network addresses
   are uniquely assigned to entities such that datagrams can be routed
   to them. Routing protocols used within the network domain are
   responsible for finding routes to entities given their network
   addresses.

NAT accomplishes this "routing" between realms "by modifying address contents in the IP header". Changing the SRC Address field in the header is routing the packet! Any further routing decisions do not involve NAT. Once the packet's address has been changed, the actual handling of the packet is performed by the "routing protocols used within the network domain". This is also what happens to packets that were received directly into that network domain. A simple implementation might do something roughly similar to this (note: oversimplified):

    |                       |        /-----------\
    |                       |       / [Firewall]  \
    \  New Packet Received  /       | unroutable, |
     \      From NIC       /        \ drop packet /
      \-------------------/          \-----------/
                 |                            ^
                 v              addr: unknown |
         +----------------+    +-----------------+
         | is DST addr in | Y  | [Packet Router] |
         | realm "WAN"?   |--->| rules: "WAN"    |
         +----------------+    +-----------------+
           N |                     addr: NAT |
             v                               v
         +----------------+   /--------------------------\
         | is DST addr in |  / "Route" from realm "WAN"   \
         | realm "LAN"    |  | to realm "LAN" by changing |
         +----------------+  \ the IP header address      /
           N |       | Y      \--------------------------/
             v       |                       | 
     /-----------\   |                       v
    / [Firewall]  \  |      +---------------------------+
    | Bad addr,   |  |      | Hand off packet to be     |
    \ drop packet /  |      | routed into its new realm |
     \-----------/   |      +---------------------------+
                     v                       |
         +-----------------+                /
         | [Packet Router] |<--------------/
         | rules: "LAN"    |
         +-----------------+
            |  To: the "LAN" firewall,
            |      other processing,
            |      maybe TX at the
            v      LAN's NIC
          (...)

NAT simply hands the packet back to be routed to the LAN. Since NAT is defined as a "transparent" routing, a NAT-translated packet should be handled the same as any other packet addressed to the LAN.

> a dumb device that doesn't route is not vulnerable

If packets going into the device are retransmitted in any way, the device is "routing" packets. Dumb retransmitting/repeating packets ix a type of routing, even if it isn't making important decisions about each packet. Fortunately, most devices include a stateful firewall that DOES make important decisions about how to handle each individual packet.

> does not make your network vulnerable.

*If-and-only-if you had that unusual NAT-only, no-firewall device - which is very different from a typical home router - it could route packets to your private LAN if they were addressed to a valid LAN address (perhaps 192.168.1.x?). They would bypass NAT and be routed to the LAN, just like the router's own communication with the LAN. You wouldn't expect NAT to touch packets sent from the router's management HTTP server to a host on the internal/private LAN.

The malicious packet might be sent from something like a smart TV" that you "isolated" in a 2nd LAN or DMZ connected to the same router. Fortunately, most routers are not vulnerable.... because they include a firewall that drops "obviously invalid" packets.

[1] https://tools.ietf.org/html/rfc2663#section-2.2

[2] Transparent to the src and dst hosts that sent/received the packet. This "transparent" is referring to the hosts using the NATing router do not need to do anything special when sending/receiving packets. The address changes are invisible to the endpoints.