In order to modify that string, even in RW pages, the attacker already has to have access, at which point the point is moot. It's like saying "if you can change memory, then you can change memory"....
They are nearly equivalent in terms of functional security.
Function isn't everything though. One example shows an awareness of the security issue and good habit being used despite the low impact. I'd argue that there is a security benefit to using one over the other.
Additionally, it's not as simple as saying "if you can change memory, then you can change memory". Memory exploits are quite often chains of small issues these days and not the simple buffer overflow of old.
For example, being able to overwrite one byte somewhere could lead to the ability to change only part of a variable address. That could be used to redirect a write to the constant string in memory.
Sure it's contrived, but scenarios like this do happen.
shows an awareness of the security issue and good habit being used.
printf("%s\n", "Hello, World!");
shows that you think "%s\n\0Hello, World!" (or however the compiler decides to lay out those strings) can't be overwritten with "%p%nHello, World!" (or something to that effect), but "Hello, World!\n" somehow can.
By that same logic, puts("Hello, world!"); is also vulnerable to DoS attack and information leak since someone could have removed the NUL terminator at the end of the string and have puts() read uninitialized/unmapped memory. Which is absurd logic.
In a lot of cases the attacker can only write to a limited range of memory addresses. If that string happens to fall in that range, they can use it to write to other addresses and/or find out where in memory certain things are stored.
So their ability to write to a limited range of addresses can be extended to a larger range.
It's also not defined whether the executable code is in RO memory or RW memory. By your argument, we should also be concerned that the attacker could modify the code directly.
By modifying the start of that string, you can begin reading and writing to various parts of the stack.
Whilst implementations may inline that string into a RO memory region - that's not defined behaviour, so you shouldn't depend on it.
[0] https://owasp.org/www-community/attacks/Format_string_attack