So I need to do an entire project in mostly-time critical code. So, using assembly seems like a good idea.
That is a false proposition. Are you saying there is not a single instruction sequence in the code that runs only once? If the code spends 90% of its time in 10% of the code, then most of the speed benefit in writing it in assembly language will be that which was spent on that 10% lines of code. Rewriting the remaining 90% will bring only diminishing returns.
Now the previous applies to speed. Code size doesn't follow the 90/10 rule: a program spends 100% of its size in 100% of the code. A word saved anywhere along program's length makes it a word shorter. The best way to justify coding everything in assembly is that it has to be as small as possible. But that may preclude it being as fast as possible. For instance, you don't get to unroll loops if the code is to be as small as possible. Or pad functions or other branch targets to align them with cache lines.
Converting to a different style of assembly language is trivial. It's nothing like, say, translating a Haskell program to C. There is no semantics involved, or even deep syntax. It's transliteration, not translation, so get over it. The GNU assembler syntax is perfectly usable for human coding and the nice thing is that it brings a certain kind of consistency across different architectures, which you will appreciate if you move from ARM to MIPS, to SPARC, to ... Anyway, why would you expect Intel syntax for a CPU that isn't Intel x86?
Rant: Intel syntax? Come on, it has insipid verbiage in it like
DWORD PTR which can be condensed down to a one letter suffix. Intel's x86 syntax is the COBOL of assembly language programming.