As already pointed out, the modularity of 2017 is very appealing and allows a very light environment which is certainly quick; as quick as the much older and under-featured 2012. Note that, during the installation, I selected the main C#/VB.NET desktop and web options and some basic Visual C++. For me, just this issue makes this version more appealing than 2015.
In its default configuration, 2017 has much more coding helps (all the bells and whistles automatically appearing when typing or moving the mouse or similar) than 2012 and 2015. This is one of the defining features of VS with respect to other IDEs, but Microsoft might have brought things way too far on this front. Nothing of this seems to affect the VS usability (quick and responsive; additionally, all these functionalities are likely to be easily disabled) and that’s why I cannot say that is completely wrong. Small details helping to improve your coding experience are certainly nice, but including too many details which virtually nobody would ever use (e.g., showing some information when placing the cursor in certain area which can quickly be retrieved in 3 different ways) doesn't seem too logical. All this is even more relevant by bearing in mind the usual evolution of VS releases: first versions full of bugs which usually take over 1 year to be fixed. They have an excellent underlying framework (almost none of the new features since VS 2008 have improved my coding experience in a relevant way), why unnecessarily making it buggy or kind of joker-of-all-trades-master-of-none? I think that Microsoft should eminently focus on delivering reliable and bug-free versions, rather than on continue adding not-too-useful features.
In general terms, I felt quite comfortable working on VS 2017 (at least, before discovering the problem below), but by basically using it as VS 2012. Note that I continued a C# (library + console) project created in VS 2012. Right at the start, I saw a curious error-over-reporting issue: a simple 1 error in 2012 clearly stating the problem (wrong definition of a class) vs. 88 in 2017 (one for the wrongly-defined class and 87 for further references to that class). I saw also other weirdnesses like expanding a tree of sub-folders in the project window which got suddenly closed. But all these things happened just once or twice and I was kind of expecting them, so I didn't really mind any of this (on the other hand, this should be seen by Microsoft as bad news: I do expect random errors and glitches in a first VS version because this has always been the case!).
The real deal breaker was the problems with the debugger: it plainly doesn't work as it should. I tested the created-in-VS-2012-a-bit-complex code, also new-2017-extremely-simple projects and the behaviour was always quite chaotic via ignoring lines for no clear reason. For example, I usually write codes including something like string string1 = "whatever"; string1 = string1;, where the whole purpose of the second line is to hold a break-point (where I will see the string1 properties via the popup window); VS 2017 skips the break-point in this second line! And this skipping-lines behaviour occurs in other situations, what makes the whole debugging process very uncomfortable right away (I have relevant experience in different IDEs and languages, VS and C# among them; I don't need to spend even one minute to try to fully understand the unexpected behaviour of a debugger to know that I don't like it). Hopefully, this is just a buggy behaviour and Microsoft hasn't actually modified the way in which the VS debugger has always worked. Another issue I didn't like too much about debugging was the fact that the break-points have to be placed in the LHS margin, in the farthest side, before the line numbers. Placing a break-point should be an extremely easy process triggered by virtually any action on a more or less wide area. If I click anywhere on the left of the central coding area, VS should assume that I want to set a break-point there; why ignoring all my clicks unless the ones located in the border-left part?
In any case, I have got a reasonably good overall impression about VS 2017 and it is likely to become my next main VS (= after SP1 is released? After 1-2 years? No idea). I assume that Microsoft will fix the problems in the debugger (at least, the line-skipping one) right away. I might even use VS 2017 for the upcoming supporting video about the referred code (it is DateParser, a new part of the multi-part library FlexibleParser. Note that I always record a sound-less video with VS showing the main features of the new part), in case that these problems will be fixed. In any case, I insist in the fact that I don't share (cannot even understand) most of Microsoft's ideas regarding how to continue evolving VS. That is, I will eventually move to VS 2017 only because of being the less-bad-alternative (= better than VS 2015 + including minor improvements with respect to the virtually-obsolete VS 2012).