“Autistic people can’t acknowledge when they’re wrong”

Obviously there are also drawbacks, but you immediately started off from an adversarial position as if it was just a completely off the wall idea. Clearly that's not the case.

In the case of a disagreement, basically start out trying to figure out where the other person's head is at with open ended, exploratory questions (stuff like "what are you looking to achieve?" or "why do you feel this is the case?"). Avoid accusatory questions like "what makes you think that?" or "do you think X is bad?" Expressing humility by, for example, stating that you don't understand something before asking them to explain their view of it helps.

Once you know their starting position, instead of simply speaking at them, instead guide them to reach the conclusion for themselves. Repeat information they've already accepted as true frequently ask them what these givens imply.

Always maintain an off ramp. If someone initially disagreed with you, odds are at some point you're going to find a sticking point where one of you is either factually incorrect or you have fundamentally different judgements. This normally is where discussion turns into argument. Give people an opportunity to save face - something like "you know I only very recently learned myself that this isn't actually true" or "you would think that's the case but there's this unintuitive gotcha in this instance" allows a person to change their position without calling their general intelligence or expertise into question. In the case of a judgement disagreement, something like "let's pretend for a moment that you desire this" let's them move forward without having to actually confront the disconnect. If someone is fatigued or aggravated, make sure there's a way for them to blow off steam, for example something like "you're making some good points, I'd like to double check my info, can we revisit this later" let's them walk away feeling good and makes you look humble while also giving them leeway to be more agreeable when you do eventually bring it back up.

At the same time, always be responsive to the other person. If they are interjecting, let them speak and take note of what they say. Again it's more important that they feel they've explained their reasoning than that you lay the groundwork for yours. When they legitimately bring up good points, acknowledge them; when it seems like they are holding something back, probe a bit; if their train of thought goes off on a tangent, explore it. While this might sound a bit tedious, especially if you already have a pretty good idea of what specific points you need to convey, a lot of people care more about being heard than the particulars of what they are saying. Ultimately, reel them back in after they've made their point and modify the logic path you're taking them along accordingly.

After guiding them through the thought process, then confirm that you have communicated your point by having them repeat back to you their current understanding. If your message was successfully communicated, it should be readily apparent. If not, it should still be evident where the miscommunication is occurring. Recursively repeat the process until the message is completely communicated. You may still not agree in the end, but both of you should be well aware as to why you disagree.

From my interpretation of the conversation, you thought the question was: "Should we rewrite the checkout page in React, yes or no?" And responded with "Why do you want to rewrite it in React?" (paraphrasing)

Meanwhile the manager thought they were asking: "Please discuss the reasons why we should and should not rewrite the checkout page in React, including your recommendation on a course of action" And you responded with "Why do you want to rewrite it in React?"

Spelled out like that it's hopefully a little clearer that the "why React" was part of the question. They don't know if the page is performing "well" or whatever that means (even from an engineering standpoint it's hard to define, render time? bandwidth? server CPU?). They might know if users are complaining about checkout being slow, but even then users tend to leave rather than complain. If you were to tell them that the checkout page was performing "poorly" and React could fix it, that's the kind of information they were hoping to obtain from this conversation.

Similarly in my machine learning question, my CIO was actually asking me "how do you think machine learning can benefit this business?" And I responded with "how do you think machine learning can benefit the business?" He didn't know, he was asking me. He had just heard about the wonders of machine learning and was fishing for how it could benefit this business. Just like your manager had heard about React and was fishing for how it could benefit the business.

If your manager were here replying to comments I'd advise them to remember that engineers in general (spectrum or not), tend to be the literal sort, and if you aren't getting the answers your looking for it's often useful to examine the words you used and ask if you are actually asking the question your hoping to get answered or relying on subtext. But for the engineer's side of this conversation, it's important to ask if the question your answering is actually what they are asking, or if you failed to parse their intentions.