Changing /admin path would bring no security benefit, because it's just hosting the single page app. Flarum has no separate authentication for the admin panel, so whatever obfuscation you put in place will be useless if regular login is also allowed, as all endpoints will always be discoverable.
What you'd need to change for security through obscurity are the API paths for settings edit, permissions and extension management, but even that would be useless without changing how the admin panel operates.
The attack vector you are trying to prevent here is using an admin account with already leaked credentials. If you customize the admin or API paths, after logging in this information would immediately be leaked to the user as part of the Flarum boot payload.
The best protections for this already exist: for credential leak/steal, require 2 factor authentication for admins. If you are concerned about cookie stealers, there's the Sudo extension to ask for password every time you enter the admin panel.
If you really wanted an additional level or protection on top of those, the best would not be to obfuscate the endpoints, but to create a separate admin password that needs to be entered when using the admin panel. The same code from the Sudo extension could be used to implement it. The code would be part of the URL, or asked in a popup each time.
EDIT: or, I suppose, the other attack vector one tries to prevent when renaming apps are CSRF or authorization bypass vulnerabilities. But all the core admin features rely on just about 3 API endpoints and they all use assertAdmin. Unless there's some sort of vulnerability in the router that lets an attacker skip middlewares, I don't see how this could be exploited. I think it's much more likely for the server to be hacked through other means.
