> Do you have any articles, case studies, etc of how to express this to management that is
  > generally oblivious to the day-to-day, in-the-trenches, experiences and pain points of developers?

It is the "generally oblivious" that is the problem. Log holdups whenever a ticket takes significantly longer than the estimate. And be specific as to what the holdup was.

  > What you're saying sounds great to me, who is a developer, but how would you come up with halfway realistic numbers for Y and X?

The same way that I come up with halfway realistic numbers for any other dev work. I pull it out of my donkey. Then double it.

  > The best thing I could think to do is have the team minutely log all lost minutes productivity
  > caused by delays and inefficiencies that the proposed fixes could address.

Yes, log it! It does not have to be by the minute. Honestly, if the holdups are only causing minutes of delays, then they're not so bad unless your ticket take only minutes to complete anyway. My general rule is to log any holdup of more than half an hour, or more than 10% of the time estimated to develop a feature/bugfix. Very loosely, of course.