We have struggled with this issue too. We generally have a /32 IP address on a "loopback" bridge with no interfaces attached and use that for all monitoring, with BGP advertising the address, to handle the multiple paths around our network. The odd thing is, it does work on some devices, but not on others. It is very inconsistent. We have particularly noticed the issue since v6.30 (I can't remember if it was an issue before then), and 6.39.3 (current bugfix) still has the issue. The affected devices are primarily CHR and CCR. The lower end devices tend to not be multihomed as often, which may be why we haven't seen it there.
I have found a kind of workaround... but I don't like it.
I have added a new static route on the device to get back to our monitoring server, using ECMP:
/interface bridge add name=bridge-VLLB-TPRK-TMNO-RT1 protocol-mode=none
/ip address add address=L.L.L.L comment=VLLB-TPRK-TMNO-RT1 interface=bridge-VLLB-TPRK-TMNO-RT1 network=L.L.L.L
/ip route add check-gateway=ping distance=1 dst-address=M.M.M.M/16 gateway=a.a.a.a,b.b.b.b,c.c.c.c,d.d.d.d pref-src=L.L.L.L
ECMP makes it use a loopback address as the source, because the route isn't just out one interface.
The reason I don't like it is that it negates the value of BGP for those management subnets. I'm sure you'll agree that static routes is something you want to avoid for traffic that you want to have failover correctly.
In case anyone at Mikrotik wants to try reproduce this, the most recent case we have is a CCR-1009-8G-1S-1S+ running 6.39.3. We have 4 upstream paths to other Mikrotik routers, using BGP to determine the best path. A bridge and loopback IP is created as per the notes above. With the static route using ECMP, SNMP to the loopback IP works, but when the static route is disabled, SNMP to the loopback fails. I also tried putting in a route filter for the BGP peers that a "preferred source" of the loopback IP to the routes learned via BGP, which made no difference.
you mentioned that it works as written in the documentation... but the documentation here:
states: "Note: SNMP will respond to the query on the interface SNMP request was received from forcing responses to have same source address as request destination sent to the router".
I don't know if the outbound interface part works as written, as it doesn't bother me. The source address does, and the documentation says that it uses the same source address as the request destination, which I understand to mean the loopback address in my use case. So this does seem to be a bug, where it's not operating in the way the documentation says it should.