Understanding when to remove Order By or Sort operator from Query/plan
As per my understanding in above scenario we do not need order by as index have those columns already sorted


That understanding is incorrect, and that plan shows one reason why.  A parallel index scan doesn't output rows in index order, as each thread reads at a different location in the sort order.  You can't expect rows in any particular order without an ORDER BY clause.

And the index does not have the rows already sorted.  The ORDER BY is on (DemoID, CaptureDate), but the index is partitioned by CaptureDate.  So if the query crosses a partition bondary, the DemoID values will start over. 

eg the rows in (DemoID, CaptureDate)-order:

(1,'20190912'),(2,'20190913'),(3,'20190912'),(4,'20190913')


may be stored over more than one partition:

partition N
--------------
(1,'20190912')
(3,'20190912')

partition N+1
--------------
(2,'20190913')
(4,'20190913')


So even if the plan used a single thread to scan the index, a downstream sort would be required.


  Plan does not have an expensive sort but stats got worst, why?


No. The stats got better.  The second query has the same 330 logical reads and only 78ms of CPU time vs 297ms of CPU time for the first query.  The difference in elapsed time is related to more parallelism and the physical IO, which is not an attribute of the query plan.  Rather it's dependent on the state of the page cache when you run the query.