Just for clarification: APIPA is Microsoft's original naming and has been standardized as Dynamic Configuration of IPv4 Link-Local Addresses (IPv4LL).
Here is what probably happens:
the Desktop has itself a route to the IPv4LL LAN, probably in addition to a more "classical" route it got by the same DHCP Ubuntu uses, say a private LAN 192.168.1.0/24.
Ubuntu has itself an IPv4LL address on eth1, let's say 169.254.5.6
When Desktop is looking for 169.254.5.6 since its on-link (directly reachable), it sends an ARP requests for 169.254.5.6 as broadcast,
Ubuntu receives the broadcast. As a Linux host, it's following the Weak Host Model: the IP addresses added to its interfaces belong to the host rather than to their interface. It's true both for IPv4 and for ARP, as documented in the
arp_filter - BOOLEAN
0 - (default) The kernel can respond to arp requests with addresses
from other interfaces. This may seem wrong but it usually makes
sense, because it increases the chance of successful communication.
IP addresses are owned by the complete host on Linux, not by
particular interfaces. Only for more complex setups like load-
balancing, does this behaviour cause problems.
so it answers the ARP request for 169.254.5.6 assigned to eth1, but on eth0 where it was asked, using eth0's Ethernet MAC address.
Desktop now having resolved the layer 2 Ethernet address, updates its ARP table and sends an IPv4 ICMP echo request packet to Ubuntu's 169.254.5.6 with destination MAC address Ubuntu's eth0 MAC address,
Ubuntu, following the Weak Host Model replies with an IPv4 ICMP echo reply to the request. Since OP tells it's working, that further means that:
either Desktop source address is an IPv4LL too and Ubuntu also has a 169.254.0.0/16 route on eth0 with lower metric (or used first anyway if equals), so the reply comes on the right side,
or more probably the Desktop is not using an IPv4LL source to query the IPv4LL address 169.254.5.6 so it's in the same IP network (set by DHCP) as Ubuntu's IP address on eth0 and Ubuntu answers on the right side too (because its routing table has an entry like 192.168.1.0/24 on eth0). This case (not using IPv4LL source) is recommended by the RFC:
Where both an IPv4 Link-Local and a routable address are available on
the same interface, the routable address should be preferred as the
source address for new communications, but packets sent from or to
the IPv4 Link-Local address are still delivered as expected.
Assuming I didn't miss something in my explanation, which case is it?
Of course this behaviour isn't entirely correct. Because each broadcast domain should have its own private IPv4LL LAN for itself, and not leak addresses to an other one.
What this means in practice, is that if a Linux host with default configuration participates in multiple such IPv4LL networks (one per interface), it might (uncertain, see later) not allow any other system to use any of its own IPv4LL addresses, or switch needlessly its own IPv4LL address even if they are not on the same side because there are collision detections. But in practice, still because of the Weak Host Model, by default multiple routes to 169.254.0.0/16 will enter the land of the Multi-Homed (mis)configuration. Usually one route only works correctly: the first among equals as displayed with
ip route show 169.254.0.0/16. Others will have working ARP, but probably not working IP routing. This requires configuring the host properly for multi-homing (in which case it would anyway probably stop answering ARPs sent to the "wrong" interface above and not trigger this problem), and integration with IPv4LL wouldn't help. Most of this doesn't happen with IPv6, because any use of a link-local address must include the interface.