Different screen readers navigate in different ways, so both modes have to work, especially if you are making it keyboard accessible for users with mobility impairments. It sounds like you aren't labeling your form controls properly. Every form field should have a <label> element using the 'for' attribute pointing to the id of the form field. You can also use aaria-label to label the form controls, but the label and the for="id" method is the most accessible. This ensures that tabbing into the field results in the screen reader announcing the label programmatically associated with it, plus allows users to click on the label to interact with and focus the form control.

VoiceOver uses both Tab and arrow keys for navigation, as does Jaws. Be sure to test on both platforms and within Safari, Chrome, Firefox, and Edge, as your design decisions may function differently within each. I primarily use VoiceOver in MacOS in Safari, using QuickNav which is all managed through the arrow keys. I'll very rarely use tab, since QuickNav has a rotor option for form controls, so I can navigate full forms using just the down arrow alone.

Yeah I think taking the time to properly label is the best bet here as others have mentioned, because it's probably close to a 50 50 split of people using tab or arrows, and sometimes (like if their are many fields close together) we might use both options.

Plus if the labels aren't read with the jump to element commands like "E" for next edit box, "C" for next combo box, "B" for next button ETC, then that's a big problem too as that's how we jump quickly between sections of a form particularly if we already know our way around somewhat.

Hi,
First, thanks for caring.
NVDA has two modes with specific purposes.
Browse mode allows the user to arrow up and down through the entire page, and use navigation commands like pressing h for the next heading and k for the next link. This is what most people will use most of the time on webpages because it provides a virtual rendering of the page. The tab key works here, but other than that, none of the keyboard commands really correspond with normal windows commands.
Focus mode is what we use to navigate sites like Reddit which have their own keyboard commands built-in, or to fill out forms. In focus mode, we generally tab through the page, and the letters and arrow keys work normally, allowing us to fill in any text boxes or select things in lists. We don't expect NVDA to read every single thing on the page when tabbing through it, since browse mode will catch those things.
You can toggle these by pressing nvda+space (nvda being either insert or caps-lock depending on your settings). If you hear a high beep combined with what sounds like a key press, you're in focus mode. If you hear a lower beep with nothing else, you're in browse mode.
So, if the primary purpose of a page is not data entry (such as a registration form), the user is probably going to be navigating with browse mode, meaning they'll be arrowing through the page and having NVDA read its virtual render of everything. In that case, it's not really important for the tab key to read everything, though it's good practice to try and make the tab key at least move to and highlight every control that someone using only a keyboard might need to access.
I hope this helps; let me know if you have any other questions.

Personally I almost never use tab anywhere with the exception being the old reddit layout precisely because of the problem that you describe, but the way I navigate web pages depends entirely on the screen-reader and operating system since they are all very different. With NVDA I just jump to the highest order heading and then navigate downwards using Control + Down unless I'm already familiar with the layout.

Tab is most common, especially with JAWS.