Symptom:
When building spoke to spoke tunnels the spokes always send aaa authorization requests to radius to obtain attributes, however they do not always apply the attributes to the configuration. Sometimes they do and sometimes they don't.

When building hub to spoke tunnels, the virtual-access interfaces on the hub always have the proper attributes from radius assigned to them.

Here is an example of a spoke to spoke tunnel that did honor the attributes:

*Jun 11 19:15:00.439: RADIUS: Received from id 1645/5 10.0.0.1:1645, Access-Accept, len 129
*Jun 11 19:15:00.439: RADIUS:  User-Name           [1]   23  "spoke2.naaustin.local"
*Jun 11 19:15:00.439: RADIUS:   Cisco AVpair       [1]   48  "ip:interface-config=description Spoke to Spoke"

Derived configuration : 342 bytes
!
interface Virtual-Access1
 description Spoke to Spoke  <<<<<
 ip unnumbered GigabitEthernet0/0

Here is the same device with the same remote spoke tested again, and this time it did not honor the attributes, you can see there is no description on the interface.

*Jun 11 20:12:43.655: RADIUS: Received from id 1645/11 10.0.0.1:1645, Access-Accept, len 129
*Jun 11 20:12:43.655: RADIUS:  User-Name           [1]   23  "spoke2.naaustin.local"
*Jun 11 20:12:43.655: RADIUS:   Cisco AVpair       [1]   48  "ip:interface-config=description Spoke to Spoke"

Derived configuration : 277 bytes
!
interface Virtual-Access1
 ip unnumbered GigabitEthernet0/0

Conditions:
FlexVPN utilizing Spoke to Spoke tunnels
AAA Authorization applied to IKEv2 profiles on spokes using radius