For the part of your question
"Also we have separate sections for Features to be tested and not to
be tested. Is this not redundant with features to be tested? Also if
we indicate the list of features not to be tested, why we need to
indicate the list f features to be tested? When features are listed in
requirement document, obviously all of them have to be tested. But
exclusions if any may be listed in Features Not to be Tested I guess."
I will try to explain this to you in a simple way. If we are both referring to the standard template of the test plan then both these parts "Features to be tested" and "Features not to be tested" come under the header "Scope". Now unless and until we define the scope it is "Undefined". This is also correct in terms of Synonyms & Antonym (Define, Undefined) and also in terms of Maths i.e. anything which is not define is undefined = infinity. So, if you don't define the scope then it means your scope is infinite and you are in trouble at that time, because "Infinite - X = Infinite".
Requirement documents are for our understanding, analysis and reference. Once you have created your test plan you should stick to it and execute your testing as per this plan only, so you should very clearly know from this plan that what, when and how you need to test and what you don't need to test or worry about.
In addition to it, the moment you say to your manager and/or client that you don't know the scope included and excluded, you are gone. Both of them want everything to be clearly communicated to whole team in black & white so that everyone is on same page, as there are always exceptions associated to Requirement documents. And as part of QA too you should be very clear about your scope of testing. Without this you are like a person in middle of sea without any magnetic compass.
Features to be tested + Features not to be tested = Scope = Requirement document, but don't say it like Features not to be tested = Requirement document - Features to be tested. As scope is being built by these two sub-sections, not the other way round.
I'm too working on a test plan where we are defining the same things, and while doing so many a times you will have to again break a use case and a features into sub parts like one of the feature is creating a new record and then digitally sign it using bio-metric authentication via a finger print scanner or a iPad. Now, out of this whole feature we can't test the bio-metric authentication part as hardware is required for the same which is not available, so we have clearly mentioned this part in out of scope section. So, that client and team know that this thing has not been validated and provided effort also doesn't include some part of the feature (a justification for effort too). Once the scope is clear and defined we can start our testing.
It is not always 'Everything or all items are to be tested' - It is this can/will be tested and this can't/will not be tested (where this = definite value); depending upon multiple factors like Resources, Skills, Timeline, Priority and Complexity etc. This is how things work practically.