Feature requests and defects are basically the same thing - somebody would like the system to change in some way, either providing new functionality or correcting erroneous behaviour. It is beneficial to have a single consolidated list so that relative priority can be applied to all of the feature requests and defects in the backlog; individual developers can only work on one thing at a time and the most important next item may be either the development of a feature or a fix for a defect. A feature request may be more important than an outstanding defect and vice versa.
With regard to the tools you mention, as pointed out in some of the other answers, Quality Center is primarily a QA tool which allows you to input requirements, define test cases and execute step-by-step tests. Where a test fails, it is natural to immediately raise a defect without changing context and Quality Center provides defect management functonality to allow you to do this. The difficulty is then in managing the process of fixing and retesting defects against the other work that is in the backlog and this is where things can get complicated. I have seen teams that have set themselves up so that feature requests get raised as 'defects' in Quality Center to give them a full view of the work backlog; this has a strange feel to it, however raising defects in another tool e.g. JIRA breaks the link between the defect and the test from which it originated.
There may be other compelling reasons to use a specific tool, e.g. if you have integrated it with your source code repository and deployment process, which may override the level of choice you have around how integrated the front-to-back process can be. The best demo I have seen of a full requirements-to-deployment solution is Rational Team Concert, however I haven't had hands-on experience with it.