As for the rest, they look the same now. But HTML is supposed to be future proof.
Suppose, in the future, people prefer emphasised text to slant backwards, definitions to hover holographically, and cites to render directly to your neural link. Or, suppose right now you want to screen-scrape a page and get all the definitions.
That's why I use semantic HTML.
It also gives context to additional ARIA attributes like aria-details[2] because now the screen reader knows that the details are the definition or whatever, and will announce those appropriately.
Using semantic elements allows you to have the proper ARIA roles (and thus the accessibility tree be properly scoped) without thinking too much or polluting your DOM tree with aria-* attributes.
There are also some other semantic-related benefits. E.g. from <dfn>'s MDN page[1] "if you include an id attribute on the <dfn> element, you can then link to it using <a> elements. Such links should be uses of the term, with the intent being that the reader can quickly navigate to the term's definition if they're not already aware of it, by clicking on the term's link."
I know you can already id-link to a simple <span>, but the thing is the screen reader would be able to announce that the link is to a definition so the user is already aware of the link purpose even before clicking it (unsure if any do this, but they could). Or maybe the user agent could build up a list of definitions automatically and allow you to quickly look up them, even if they are not explicitly linked.
Most importantly: you might think that sighted users cannot tell the difference between the default styling of all those elements, but they often can by virtue of what they are visually surrounded with and other contextual clues that are not available while using a screen reader. E.g. `<cite>` is often surrounded by other visual cues that might not be obvious to screen reader users which have a very local and narrow contextual scope (you can only hear elements one at a time, while visual users can see a bunch of context at a glance).
Also, sighted navigation is much faster than navigating via keyboard+narration so the additional affordances really help non-sighted users. Imagine having to wait for a whole paragraph to be narrated to get to some textual clue near the end of the paragraph, or even further down the content... or worse, above the current content (think an <h2>Definitions</h2> for example) which will normally not get visited while you navigate piecewise. It's very hard (impossible?) to read/navigate diagonally with a screen reader. We get so much instant info visually that we take for granted and it's just not there for screen reader users.
Lastly, you can style those differently in CSS even if the default user agent stylesheet does not. E.g., by giving <dfns> a dashed underline or a different mouse cursor. I know you can do that by manually annotating <span>s with classes but the thing is... you don't need to. So you can give additional visual affordances to sighted, but also to cognitively-impaired or partially-blind users too.
[0] https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
[1] https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
[2] https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
[3] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/df...
<dl> lists with their <dt> <dd> elements are fine to use but screen readers rarely convey their roles.
a11ysupport.io is not comprehensive and its volunteer data is not kept current but it still offers a sense of the divide between what's theoretically possible and what actually happens.