Sure, in no particular order:

>> You need to do some real testing

> I find this aggressive.

> Although you have clearly decided I haven't... I have. I just think people making real arguments against the using numeric input elements is off. I've used them for years now without encountering the edge cases people are throwing out there

I don't have users. But I do run into problems with number inputs in the ordinary course of my personal life. I tend to suspect that's related to this observation of yours:

> browsers differ in how they handle value changing on scrolling for number fields (Chrome: no change, FF: value changes)

But if professional testing can't turn up a problem so common that the internet is full of warnings and complaints about it... something's wrong with the testing.

---

> I sorta get how this behavior doesn't translate well for the number field. I will note you can easily stop the behavior with onscroll="return false" attribute or a JS event listener with event.preventDefault() ... I've seen both in the wild and they're fine solutions.

The idea that these are "solutions" conflicts with the idea that the behavior isn't a problem to begin with.

> Even for no-JS users I think it's still OK since they've consciously opted-in to the default browser behavior for stuff like this.

I can't agree with that; rather, this is a cost they pay, generally without even being aware of the particular functionality, in order to prevent JavaScript from doing nasty things to them. The idea that if they don't want to be abused by your JavaScript, they deserve to be abused by your passive-aggressive HTML design is... strange.

---

> So, Safari is on 15 and according to https://caniuse.com/usage-table [5.1] is 0.02% the market share.

I tend to agree with you here. Safari 5.1 is too rare to be worth much attention. But you placed heavy emphasis on the idea that the reasons the UK article gives for avoiding number input types are outdated, and they aren't. Safari 5.1 is not meaningfully older now than it was two years ago. Number input behaves no better now than it did two years ago.

---

> I mean. Yeah - I guess I expect the section named "Accessibility" to be about the concept of accessibility.

That section is focused on the jargon meaning of "accessibility" as "making it easier for disabled people to use [whatever]". But there is no reason for "accessibility" to be the exclusive province of the blind - "people with mice" have concerns too.

(Even there I'm being too generous - as with other forms of idealized equality, you can see misguided pushes to achieve equality by making [whatever] worse for everyone, as long as the new lower quality is equal for normal people and disabled people. And I can't really see another way to interpret advocacy of number input - you want to make your website less accessible to everyone on the theory that a small number of people might not suffer a relative disadvantage in using it. Don't do that.)

-----

Number input is designed badly enough that MDN, and the HTML spec, both warn you that you probably want something else. That should be a hint that you want something else. Use the tools that were developed to provide the good things that number inputs provide, without also doing the terrible things that number inputs do.