That is probably an influence, yes. In general, increased warnings have always been a goal for gcc, and they are a natural part of development of newer optimisations - optimisations need more code analysis, and when that can be used to spot possible code errors, the gcc developers aim to give that information back to the user.
Another major influence in recent years is the competition/cooperation with clang. The gcc folk saw clang's comparison page showing how much clearer and more informative the warnings and errors were from clang than gcc, and took it as a challenge - later gcc versions had much more useful messages (colour-highlighted, indications of the error point in the line, and far more readable C++ errors), and gcc and clang compete on how many errors they catch. Simultaneously, the two projects cooperate on the "sanitizer" series of run-time checkers, though they are not so relevant for most small embedded systems.
The whole point of that sort of thing is to allow the compiler to do more work, with less work at run-time. In particular, by having bit-precise simulation of things like floating point arithmetic on different targets, the compiler can pre-calculate values at compile time that previously had to be done at run-time in order to get exactly the expected value. These things can be helpful in some code - but the cost is a rather large maths library included in the gcc packaging and build. From the viewpoint of the gcc developers, this is cheap - they just include an existing well-known library, and then they have the new toy in their toolkit. It doesn't matter that this library increases the complete source code of gcc by 50% (or whatever), or that it is mainly useful on different targets or hosts than the one any particular end-user is interested in. Disk space is cheap, and toolchain compile-time is cheap (few people build gcc themselves). A few MB of gcc source library to give a few percent speed increase on the target at run-time is definitely worth the tradeoff.
In embedded work, you should /never/ expect guaranteed consistent results from different toolchains. If you have a project that is built with a particular toolchain, you don't change that toolchain or its versions without very good reason and a lot of extra checking.
For most uses, running gcc with "-Os -Wall -Wextra" is going to give you pretty good optimisation, and a good selection of warning messages. If you want more control, you need to put a little effort into reading the manual - it's all there on a few pages. And if you want more features - gcc has /many/ - they are in the manual pages too, and you need to read about them to use them.
That is just the same for every other compiler that has ever been made. gcc only differs in that it is a big system, with a lot of options and capabilities. (The other main compiler for ARM devices is clang, and it too has lots of options and extensions.)
Agreed.
But then, I have always been the sort of person that reads manuals, even for tools that I don't have...