SQL server 2012 reports "Missing Index" on column which is covered by "Clustered Index"
It is trying to filter[1] by section_id but not quotation_id - it can't do this by seeking on an index on quotation_id,section_id so it will have to scan that index (which as it is your clustered index, is the whole table). It would be able to use an index on section_id,quotation_id for this because the target columns are first in the index's key.

[1] or possibly sort, as we can't see the query or the full plan we can't know which or why. In the case of sorting it will be wanting the index for slightly different reasons, perhaps to replace a clustered index scan and spool to tempdb for sorting by scanning the non-clustered index and pulling the other data out in order more directly.


  I was under the impression that Clustered indexes are used by query optimiser even when non-clustered index seek is performed


That is correct. It will use seeks on the non-clustered index to find the clustering key value, then use that to find other data needed from the row. Unless it only needs data from columns in the index - in that case there is no need to refer to the clustered index as all the information is already available without.

Note that this is essentially the same if you don't have a clustered index. Instead of containing the clustering key each non-clustered index contains the rowid of each record in the heap instead.


  Does adding the missing index (as reported by SQL server execution planner) is a good idea?


For that query as it stands, quite probably (though with the caveat that we don't know what the query is, or the query plan that was used, so it could be that refactoring that would be more useful). It would likely allow the query to be processed by seeking on that index then performing lookups on the clustered index as needed instead of scanning the whole clustered index, which the planner expects to be a significantly more efficient way around.