It's hard to say what someone else's concern could be without being in the room. I wonder if the "burn" talking-point is an example of more general concerns.
The linked code is a "minimal example" in a tutorial. It contains
burnFrom() functions that are not part of the ERC20 standard. https://eips.ethereum.org/EIPS/eip-20. Those are both red flags for code that's supposed to be carefully constructed and well-understood.
Nothing in ERC20 forbids extension of the basic interface, so technically it is not a violation of the rules to add functions. If I were cross-examining your technical team, I would question why you need those functions to see if you have carefully considered answers, and if not, question why you have unnecessary code in your contract.
Exchanges have been burned by non-conforming ERC20 contracts that failed to observe subtleties in the spec. The README for the spec itself refers to two well-crafted implementations which begs the question: why are you using a minimal example from a tutorial?
It's not that it's a year old or using an old compiler, in my opinion. Afterall, bytecode is meant to work forever. However, since it is merely a tutorial, what assurances have you received that the code has been subjected to meticulous scrutiny? In the case that there is no assurance, no publicly available audit or quality assurance report, then have you engaged anyone to review it for you? You can see where that would be leading. What is your process, why is that way, how deep is the team's knowledge and why should we trust their thinking?
If you are presenting a copy/paste job from a tutorial and seem unaware of the possible implications, that speaks volumes about the potential for oversight in the token contract itself, and also in the broader scope of the contracts that use it. Tokens are generally useless unless coupled with a line-of-business app which will potentially have access to destructive processes that may or may not have a worthwhile purpose.
Exchanges are not in the quality-assurance business. It's not their job to review your code. It's your job to assure them that all risks are professionally and satisfactorily addressed.
Again, we may never know exactly what they are thinking. The foregoing is not meant to sound excessively critical. My intention is to convey some insight into how this may look from a risk-averse perspective.
Hope it helps.