Having taken the path of building a project using Habitat (in Sitecore 8.2, not 9) I can give you the following points:
Good example of how to structure a Helix solution.
Some useful Foundation modules which you could re-use. Some of these help you to adhere to helix guidelines such as the Multisite foundation module which includes a Datasource configuration feature to allow you to set site-specific datasources for renderings.
Can probably re-use Project\Common module as this consists mainly of bootstrap related structures.
Bloats your project with lots of code you won't use
You will spend time removing Feature modules (or if you leave them in your solution, you will slow your build and synch processes), OR
You will spend more time trying to adapt Feature modules to suit your needs than you would spend building from scratch.
You will need to learn about the Habitat build process and will likely have to modify this if you use the solution in a CI process. This might take quite a bit of time if your usual build processes are very different.
I would look at Habitat as a useful solution for first learning about Helix - if you create some sample modules it will be good practice for working in this manner. But do this with the goal of learning, not building something for a client project.
Another way to think of it is: do you prefer (and is it quicker) to create your own solution, a greenfield project; or do you prefer to work with an existing solution knowing that you will add the learning curve for this existing solution to your work burden.
I've upgraded Habitat to Sitecore 9 and there are several things to note. There's an existing Github PR for SC9, so you may want to check the progress on that too. In the meantime, here are things to watch out for (not inclusive of course):
If you're going to use SOLR (the default from the install), you will need to update the configs (particularly field names) and some code such as the constants to reflect field names and facets handling. Since the ContentSearch API mostly abstract any provider specific code, most of the code works.
You will need to switch from the DynamicPlaceholder module to the built-in DynamicPlaceholder. You can simply remove the dependence to the module then update the HtmlHelper to use the native one (and update the Views if you're using them)
XConnect is the biggest change and thus the biggest challenge depending on how much xDB code you have. So, if you are using the Demo code and SitecoreExtensions in Habitat, you will need to rewrite most of those.
Remove the old WFFM Forms. Use the new one. Although WFFM should still work, it's being replaced obviously. So, Habitat code for WFFM like the Outcome action will need to be replaced if you use it. FYI: Experience Forms doesn't allow site-specific forms location in this version. I've reported that to Sitecore already.
Like #3, since Marketing Automation is part of xDB, if you were using previous versions and have code against it (i.e. the Demo project has code to look at the user's Marketing Automation state), then you will need to redefine and recode all of that as well.
Anyway, SC9 to me is like SC6 to SC7. It's a major update specifically architecturally. It's definitely for the better. As what everyone else said, Habitat is an example but has some really good software architecture concepts in it. But it's not for EVERY project. So, pick and choose.