Tell them this is only an amateurish name for the Root Cause field used by professionals (when issue tracker does not have dedicated field, one can use comments for that).
Search the web for something like software bug root cause analysis. there are plenty of resources to justify this reasoning 1. 2. 3. 4.
. a root cause for a defect is not always a single developer (which is the main point of this field).
That's exactly why "root cause" is professional while "person to blame" is amateurish. Personal accountability is great, but there are cases when it simply lays "outside" of the dev team.
Tell your boss when there is a single developer to blame, root cause field will definitely cover that ("coding mistake made by Bob in commit
1234, missed by Jim in review 567" ). The point of using the term root cause is to cover cases like that, along with cases that go out of the scope of the dev team.
For example, if the bug has been caused by faulty hardware (with the person to blame being someone outside of the team who purchased and tested it), the root cause field allows for covering that, while "single developer to blame" would simply break the issue tracking flow.
The same applies to other bugs caused by someone outside of the dev team - tester errors, requirements change, and management decisions. Say, if management decides to skip investing in disaster recovery hardware, "blaming a single developer" for an electricity outage in the datacenter would just not make sense.