Can adding a columnstore index to a table affect read performance of a query that uses a rowstore index on the same table?
Adding the nonclustered columnstore index allows for a batch mode sort in the second execution plan.  This causes all of the processing to be done on one thread - so even though the query has a parallel plan, it's essentially running serially.  You can see that by looking at the details of the different operators.
I reproduced your problem locally, here's the sort operator with per-thread counts - as you can see, everything is on thread 1:

Notice the &quot;Actual Execution Mode&quot; is &quot;Batch.&quot;
Everything after the sort (the nested loops join, key lookup, etc) is essentially serial, which is what slows the query down.
See this KB article for details and possible solutions:
Adds trace flag 9358 to disable batch mode sort operations in a complex parallel query in SQL Server 2016

Batch mode sorts were introduced in SQL Server 2016 under compatibility level 130.  If a query execution plan contains parallel batch mode sorts in conjunction with directly-upstream parallel operators, you may encounter degraded performance compared to row mode sort plan equivalents.
This occurs due to a parallel batch sort outputting fully sorted data via a single thread to the upstream parallel operator (for example, a parallel merge join operator).  The performance degradation occurs when the upstream parallel operator uses single-threaded processing due to the incoming single-threaded batch mode sort operator.

For completeness, the options outlined there are either:

enable TF 9358
enable query optimizer hotfixes (through TF 4199, the QUERY_OPTIMIZER_HOTFIXES database option, or the ENABLE_QUERY_OPTIMIZER_HOTFIXES query hint)


Getting rid of the sort is another solution for this problem.  The sort is only present to try and prevent too much random I/O from the nested loops join, which is using unordered prefetch, as mentioned in this article by Craig Freedman:
Optimizing I/O Performance by Sorting – Part 1

The plan uses the non-clustered index to avoid unnecessarily touching many rows.  Yet, performing 64,000 random I/Os is still rather expensive so SQL Server adds a sort.  By sorting the rows on the clustered index key, SQL Server transforms the random I/Os into sequential I/Os.

You can get rid of the sort by:

eliminating the need for the key lookup (by selecting less columns, or creating a covering nonclustered index)
disabling nested loops prefetching by adding (undocumented, unsupported trace flag) OPTION (QUERYTRACEON 9115) to the query