KARAM_SIDHU file permissions are rarely the biggest security issue.
Ideally you would run each website on its own process using a different shell user, and make sure the files for each website are owned by that user, and all files that should never be modified owned by a different user but allow the webserver user to still read them. But I am not aware of any hosting system that uses that approach, it's easier to contenerize the sites if you want that level of security.
If your host only has root and webserver user, you will not get much added benefit by tweaking file permissions because if either account gets hacked your server will be compromised.
The only approach that I think would make sense is to have "3" users. Have root but don't use it for anything web related, have a shell user that runs Composer commands and owns all Flarum skeleton and dependency files, and finally a webserver/PHP user that the webserver runs as, that's also used for any Cron or queue and owns the storage and assets folders. This would ensure that if a malicious PHP file somehow gets executed, the script should not be able to install a backdoor in Flarum itself. Unfortunately since the PHP user requires access to the Flarum configuration file, it will still be able to steal any data from MySQL, redis, etc. Even if the PHP user cannot read anything else it would still be very bad if it got hacked.
If the hacker only cares of turning your server into a botnet or crypto miner it doesn't matter much either, it would benefit if file permissions allow to compromise the Cron or Queue configuration so it can run without timeout.
This is all the theory and I'm not even sure it holds for Flarum because since views and formatter PHP files get pre-compiled and stored in storage folder, a malicious actor with the minimal permissions could still place their malicious code in those files to achieve what I described above.
If you are on a shared hosting, you probably won't have much flexibility and should just follow your host recommendations.
So in short, I'd just say make sure your vendor folder and config files are not exposed publicly to reduce the risk of a dangerous file being used for remote code execution, that your database contains only Flarum (no other prefixed tables in a single database) and the database user is only used for that database, and that the database cannot be accessed remotely. And keep Flarum and extensions up to date. This will cover most issues.
