MS support has confirmed a bug in SfB that prevents proper normalization and matching on transfers from Exchange Auto Attendants. Still working the case but wanted to warn others using Sip trunks so they hopefully avoid jumping into this problem.
If you have Exchange auto attendants (ours are Exchange 2013) and use menu navigation to transfer to SfB users and/or response groups, the SfB front end doesn't properly normalize and match numbers. This causes calls that previously were matched and properly routed internally under Lync 2013 server to instead be passed back out to the sip trunk provider (that is, assuming you have a route set up for either Site or Global voice policies - if you only have user policies and don't have a user policy assigned to your ExUM contact for the AA, the transfer will just fail altogether with the "blind" transfer event log error).
Assuming that your users have publicly routable DIDs, then having a Global or Site voice policy with a route will allow AA transfers to such users to succeed, since the number will pass back out to the sip trunk provider and return right back to SfB and get routed (the normalization bug only appears to hit calls from AAs).
If however, like us, your response groups use fake numbers that only route internally (+12345556789 for example), these transfers will still fail because the sip trunk provider won't recognize the number and will 404 the call.
We are still working with support on figuring out:
1) a workaround for the RG issue - granting a voice policy and/or dial plan to the ExUM contact and RG object does not help
2) what it is that causes the SfB front end to behave differently than Lync 2013 frontends and fail to normalize and thus match the internal numbers
Will update as we learn more.