In some circumstances, hiding software identifying information can be considered beneficial to the overall system's security, not to expose it to risks of being targeted by 0-day exploits, or make it generally easier for the attacker to find possible exploits without doing much research on what software he should target, and increasing chances of being exposed in the process.
Scanning for banners (as these signatures are sometimes called by attackers) can be difficult to detect, if the software itself doesn't makes it trivial for the attacker to collect it, so removing any such signatures or changing them to arbitrary non-identifying values is often recommended, for example on web server software (Apache, IIS,...) that might by default publish even what operating system they're running on.
In your case however, discovering what web framework some website is based on (especially the most common ones, like the ones you mention) is fairly trivial by simply inspecting response HTML / CSS / JS for signs of common building blocks these frameworks rely on (and sometimes even on what domain or web hosting server they're published), so I wouldn't really say you'd be hiding essential information that is otherwise impossible to determine by other means. Adding, or removing a line "Powered by..." in / from your response footer (or anywhere else) in my opinion doesn't change a thing for high level software stack (but you might want to omit what OS it's running on, e.t.c.).
Most websites built on such frameworks will be far more at risk of being targeted by automated web bots looking to inject malicious code by commonly known exploits, regardless if your website is built on this or that framework / CMS / whatsitcalled, not even bothering to look at your signature information. And more targeted attacks really won't have hard time figuring what underlying framework it's built on. You would be by far better off by "obfuscating" paths to your CMS, and focusing your attention on hardening web application security by running vulnerability scanners on them on your own and eliminating any potential vulnerabilities they came up with, for example.
