Assembly language is defined by the assembler, the program. It is up to the author(s) to pick the syntax. An assembler could choose to have the syntax
bob pickle,(jar)
and that would be perfectly valid syntax to store one register into the address defined by another. could probably even use the equivalent of a #define in some assembly language syntaxes.
The why question really means you want to talk to the actual developer who is likely not trolling Stack Overflow, although you might get lucky so this question does not have an actual answer.
To have a chance at success it is in the best interest of the processors developers to create or hire someone to create an assembler initially and later toolchain for their new processor, which would include someone sitting down and examining the machine code and creating a language from that. A chance at success for a third party assembler for a target involves using a syntax for the instructions that resembles those of the original, but why bother making a new one if you are not going to mix it up. The instruction syntax is only a part of the whole language defined by the assembler and you will find wide variations for mips, arm, etc, and will over time for risc-v although the desire to make new tools has gone down dramatically over the last couple of decades.
The only rule a successful assembler has to follow is the rules defined by the logic, the syntax can be whatever they choose for whatever reason they choose. So you have to ask each author/team if you want to know, not sure that even Bugzilla would get you there.
A related why question is since we spent so much of our early life with the destination on the left
y = mx + b
and not
mx + b = y
What sane person would design an assembly language where the instruction part has the destination on the right, even the high level languages don't do that.
A possible answer to your question is that someone way back was lazy and used the same code for load/store, and or cut and pasted it. And the at least RISC folks that followed, followed that convention.
Not just for Intel but for all the major/minor instruction sets you find syntax incompatibilities across tools, x86, arm, mips, msp430, avr, 8051, 6502, z80, etc, and eventually risc-v if not already. The folks that add targets to gnu assembler must take pride in making incompatible assembly languages as they do it so often.
The location within the instruction is generally irrelevant to the assembly language. The authors start off either being in the destination first camp or destination last camp.
add r0,r1,r2 ; r0 = r1 + r2
add r0,r0,r2 ; r0 + r1 -> r2
and then names of registers is free form and sometimes varies. ax, %ax. r0, $0
A recent (horrible) fad I assume coming from mips and its use in school of v0, a0, t0, etc...and that infecting other unrelated instruction sets. The mangling of different instruction set habits is happening a lot these days.
They choose how to indicate indirection @r1, (r1), [r1]...
How to indicate pre/post increment/modification and so on as they work through the instructions.
Some choose 4(r1) where another would use as [r1,#4]
First assembly languages or heavily used for an individual play a role in how they like to handle others, some folks just have to make their own tool to avoid having to learn another language or deal with what they don't like about another language thus the AT&T thing, possibly the gnu assembler choices. Definitely the way MIPS handled a calling convention and how that notion, feature?, infected other tools and possibly classrooms.
Look at the evolution of x86 assembly languages in particular (the AT&T vs Intel being irrelevant to what I am talking about) over time.
As it should be, you simply learn the language that assembler uses and move on, or you write your own assembler to match the language you prefer, if you publish it and others like it then it can work its way into the norm and you are seeing that happen.
Short answer, because other assembly languages do it. Because you can see a clear connection between risc-v and MIPS in their design, no doubt the authors of the documentation also followed along with a MIPS style that they had been used to leading up to RISC-V. Exceptions to the rule happen, while it would be more of a purist solution to always have the destination left. What is more important is consistency as you pointed out. Don't have one flavor of store one way and another flavor another. Look at MRS/MSR in a typical ARM syntax, destination/source is in the middle, in the same place.
As far as gnu assembler goes, binutils is open source you are perfectly free to switch it around, likewise you are free to create your own assembler with the ordering and syntax as you wish. If you want it to be part of a chain then as with the current toolchains you need to create/change the compiler to match the assembler and linker.
If this is strictly a "why" question, then it is primarily opinion-based and should be closed. The author of the documentation and author of the assembler (backend) were free to choose and this was the choice.