The source address selection is quite involved and specified in https://datatracker.ietf.org/doc/html/rfc6724, but from what I remember, rule 2 should make sure that if a link-local address is present the appropriate scope will be selected. So I'd rather not touch that by enforcing it. E.g. what if, for whatever reason, the interface does not have a link-local address. With this change the source address selection will always fail then. So there must be another reason why a global address is picked in your case. Usually, a link-local address should be picked.

Right now gnrc_netif_ipv6_addr_best_src() just returns the first address of the candidate set - shouldn't we still try to prefer link-local addresses if the destination is link-local?

The candidate set is just compromised of all valid addresses on the interface, there is nothing really involved about this function.

How about

--- a/sys/net/gnrc/netif/gnrc_netif.c
+++ b/sys/net/gnrc/netif/gnrc_netif.c
@@ -1019,7 +1019,7 @@ static int _create_candidate_set(const gnrc_netif_t *netif,
     /* currently this implementation supports only addresses as source address
      * candidates assigned to this interface. Thus we assume all addresses to be
      * on interface @p netif */
-    (void) dst;
+    bool ll_prefer = ipv6_addr_is_link_local(dst);
     for (int i = 0; i < CONFIG_GNRC_NETIF_IPV6_ADDRS_NUMOF; i++) {
         const ipv6_addr_t *tmp = &(netif->ipv6.addrs[i]);
 
@@ -1047,6 +1047,10 @@ static int _create_candidate_set(const gnrc_netif_t *netif,
         if (ll_only && !ipv6_addr_is_link_local(tmp)) {
             continue;
         }
+        /* prefer link-local source for link-local destination */
+        if (ll_prefer && ipv6_addr_is_link_local(tmp)) {
+            res = i;
+        }
         /* "For all multicast and link-local destination addresses, the set of
          *  candidate source addresses MUST only include addresses assigned to
          *  interfaces belonging to the same link as the outgoing interface."

Why pick out link-local? According to rule 2 this should hold for all scopes, right?

It certainly is convenient to use link-local addresses in the context of 6loWPAN

The RFC you referenced even says

The destination address selection rules give preference to destinations of smaller scope. For example, a link-local destination will be sorted before a global scope destination when the two are otherwise equally suitable.

Now _create_candidate_set() doesn't do any sorting as is, but giving preference to link-local would be an easy addition.

edit ah sorry I completely missed the _src_addr_selection() function.