Updated to provide an alternative solution.
Updated to include an additional use of the command.
Essentially, no, this should not work. The reason is that the arp permit-nonconnected command mainly applies when using bridge-groups or when you have NATs configured for IP addresses that are not in the same subnet as the interface itself.
Let's start from the beginning.
Routers are fundamentally used to connect networks. The goal is to let things talk. That's why they have things like "proxy-arp", which is when the router responds to an ARP for an IP that is not itself, saying "send it to my MAC", because I will forward it. The router is capable of responding to an ARP request for any (and every!) IP address on the planet (providing the request entered an interface where proxy-arp is enabled), because it is being helpful to the hosts on that local subnet. (Proxy-arp isn't applicable for anyone who is not in the broadcast domain, because ARPs are broadcasts.)
In contrast, firewalls are fundamentally used to limit connectivity and provide security. The goal is to analyze traffic and ensure rules are being followed. That's why firewalls don't have things like proxy-arp. Basically, the firewall is unwilling to forward traffic for a host unless the host is following the rules, and is forming packets correctly.
I know what you're thinking: "Everybody says the ASA can do proxy-arp! The documentation even says so!" Here's my opinion on that: Cisco has labeled it wrong. Proxy-arp is when a device responds to an ARP request on behalf of a different device. In reality, what the ASA is actually doing is responding to an ARP request for an IP that is configured upon the device (like, in a NAT statement), found in the config of the ASA. The ASA is legitimately responding to the request, saying "send it to my MAC", because that is me! Subsequently, it then translates headers, or whatever! The point is that the ASA has the IP address configured. The same is NOT true when a router responds to ARP requests for IP addresses it has no knowlege of.
Okay, so what does arp permit-nonconnected actually do?
When you configure the ASA with bridge-groups, the ASA (being a security device, remember?) will keep track of an ARP table in a similar way that switches keep track of MAC tables. (This is called the ARP cache.) The ASA will only pass traffic between the left and right halves of the bridge-group if the MAC and IP addresses in the packet agree with the ARP table that the firewall is tracking. So, if a host is being lured by a man-in-the-middle attack (happening at layer2 with ARP), the ASA will see the MAC address and the IP address of the packet and notice that they do not agree with the table the ASA is keeping. Thus, the ASA will drop the packet.
If a packet arrives at the ASA (when running bridge-groups) and the ASA does not have an ARP entry for the IP, the ASA generates an ARP request to build that ARP cache entry. By default, the ASA will add ARP replies to its table only if the ARP is for the directly attached subnet. If you need ARP replies to be populated in the table for subnets that are not directly connected, you use the arp permit-nonconnected command.
A second use for the command is when you have NATs where the inside-global IP address is not contained within the subnet of the firewall interface. In this scenario, the ASA will happily discard ARP requests for the inside-global IP address. If you apply the arp permit-nonconnected command, the ASA will respond to those ARP requests with its own MAC address. A workaround for this is to apply a static route at the upstream layer3 device to point at the ASA. Then the ARP request is not for the inside-global IP address, but rather for the ASA's own interface. This workaround is not always possible when your ISP is difficult to work with.
So, in your lab scenario, I think the ASA is doing exactly what it's supposed to. If you swapped out the ASA for a router, and you configured "ip proxy-arp" on the left interface, I think your entire scenario would work as expected.
Here's another way to handle the situation. If you set the arp permit-nonconnected back to default (which is to remove it using no arp permit-nonconnected), and then you apply identity NATs for the inside subnets, the ASA will essentially perform the behavior you're expecting.
object network inside_transit
subnet 209.165.0.4 255.255.255.252
nat (inside,outside) static inside_transit
object network inside_net
subnet 10.0.0.0 255.255.255.0
nat (inside,outside) static inside_net
