Looking from the end user's perspective, it really doesn't matter at what address you publish CMS as long as everything works as expected and they're accessing it without problems.
From developers perspective (and I've written and published many as well) it's slightly more convenient publishing it at the same physical location as your front-end, and keep the URL at the same level to the front-end that it 'manages contents of'. This way, you're able to use same configuration files for both front-end generating applications as well as your CMS (or at least keep large portions of them the same, if they need to be separate files), and also avoid problems with relative paths pointing to different roots. It's not the end of the world doing it differently, but would involve a bit more work in most cases.
From security stand-point though, things get a bit tricky. Using easily recognizable URL paths to your CMS means you'll be dealing with potentially a lot more direct attacks, where you won't have time to react to blind guessing, blocking URL scanners even before they hit your CMS with malicious requests. That's fine, if you're confident in your web application security protocols, and in some instances it's even desirable (when web app is also the honeypot). If it isn't however, and you depend on externally managed honeypots (security server mods, log analyzers,...), you might want to rather decide on a non-obvious URL for your CMS, so your honeypot has time to react to 'script kiddie' type requests and block them out. In this latter case, it's also a good practice to 'anonymize' all external requests, such as CMS users opening external URLs through it, where the request referrer (your CMS location) might show in third-party web server logs. Writing an 'anonymizer' script through which you can delegate external requests is easy enough, and it only takes a single JS function call in your CMS main template to enable support for it.
With all this in mind, I'd suggest you host your CMS in a non-obvious URL, at the same level relative (parallel) to the front-end root, but physically at the same location for convenience of developers/designers and debugging purposes, as well as some 'security through obscurity', at least enough to catch the most obvious 'crude' with relative ease before they manage to do any harm. Of course, you should never depend solely on 'security through obscurity' and should always have other protocols in place when the former fail (which they most surely will).