Hey @Sophiaa,
giving you the perspective of someone working mainly with Java and Sonar products for over 6 years now and also administering SonarQube Servers (and a bit of Cloud) for one of my old companies for a bit more mission critical medical applications as well as pet projects and my current company. Nowadays I’m not working on something mission critical anymore but that experience (and very picky developer colleagues) was highly valuable.
Back then there were less rules in total but we started out with the normal quality profile (as a copy) which worked well. Then we enabled more rules like one by one or in batches and only when our developers (roughly 100) complained about one heavily (like a silly thing not working great with our own formatting or due to legacy code “standards”) we disabled them again. Due to mission criticality we kept, back then with the old mode, all the ones that are critical, major, and medium enabled. Every time we updated the server we consulted the changes in the rules themselves - a bit tedious - and adapted. Worked well.
For the (new) architectural rules I would nowadays honestly keep that with the software architects working on the project. These work pretty well when starting a new project but not when having legacy code IMO that is huge and a mess.
For pet projects, and nowadays with my company and my own projects, I honestly stick to the default quality profile. If some rule annoys me too much, I try to adapt nowadays (I used to disable them back then, not the best TBH) and if that does not work, then I disable it - it is a tool not an all knowing entity. I would not say that it slows down due to us checking both in the IDE with the plug-ins and pre-commit hooks (if possible) and PR checks. And only in very minor cases - like PR has no issues but on the main branch issues now pop up, that can be a bit confusing because we have to fix them again in a PR. Happens super rarely but if it does, it can be a bit annoying.
And back then when I started developing it was a really great tool to learn and improve my skills, that’s why I also promote it to juniors or fresh graduates. It is a very good companion.
For my experience I would say it improved the code quality indeed most often by making the code less buggy. Yes maintainability is also an aspect but this one is less visible in my experience when already following company wide standards.
I also never had the impression that it felt like a checklist tool that we would tick off one box after another until the Code Quality gods were satisfied. But our code was also always flawless. No I’m kidding, it was legacy and horrible but over time it got better while following the rules and implementing new code accordingly.
One last thing: When you start with SonarQube and analyze for the first time, don’t get the shivers of all the stuff it complains about (e.g. when you have legacy code, probably older than you are). Focus on the high critical issues there are and for the rest: The code will improve while you develop, refactor, etc. over time and focus on the new code.
This sounds and feels like a “marketing phrase” but from my experience they are god damn right 
Please take this with a grain of salt and take in mind that this is only my personal experience!
Cheers 
