What types of products do datasheets make sense for?

I believe that many of the new gen companies might be using datasheet as a product overview document. Perhaps just calling it Product Overview or At-A-Glance versus Datasheet is better. Datasheet might need to be more in-depth and technical. Given the # of cycles of feature releases, datasheets become outdated pretty quickly. Also, there might be "legal binding" on datasheets as a factsheet for the product, in-sense, you could be sued if something doesn't work as you said it would. Product At-a-glance or Product Overview, might be a way out of it. 

Datasheets are still a bread and butter artifact in B2B. Over the past 10 years, best in class datasheets have gotten much more visual and easier to scan. The days of paragraphs of text are long over. 

As far as "features" go, they are generally the least important thing that go into a datasheets. Yours should be problem/solution/benefit/differentiator oriented. Those things don't change nearly as often as features. But, as things do change, you need to update your collateral. 

It could just be a naming convention, as we tend to produce sales sheets/one-pagers, which serve a similar purpose. As Mike mentioned, we focus on the problems and value rather than specifics of features. It serves as a high level 'why does it matter' document, that does not necessarily need as much tinkering with additional features.

Datasheets are still very valuable. We structure our data sheets to hit on the industry overview/challenge, our benefits/value and then wrap up with a section to some of our high-level features. Even in the features section, we lay it out more like a check list with value statements instead of loads of text because we noticed our prospects wanted to consume the information as fast as possible. "Just tell me you have it and why its good..."

We have two releases a year on our technology, so we update our data sheets during the release cycle, towards the last sprints when our dev team is at code freeze so that we can safely get screenshots and know that nothing has been cut in development at the last minute.

Yes. Datasheets are still relevant and important. They are not going to close the business or even move you much in the sales cycle but they are an important asset. Especially during the introduction phase with a prospect. I have two proof points for this. 

• We are an early stage startup and I get asked for a data sheet (or I face a scenario that could use a data sheet) multiple times a week. When you are introduced to a potential prospect or practitioner in the industry you are selling, it is very common to be asked - "Is there anything I can review in advance?". Also, be prepared to have different data sheets that cover different markets or buyer personas to maximize your introductory discussions. 
• Our customers are marketing teams of small and mid-sized tech companies that use our product to manage content and enable sales. Irrespective of the size of the company, they all have a few content types in common. And Datasheets (along with Case Studies, White Papers & Blogs) rank at the top of the order. Even a 15 person company has Datasheets in their arsenal. 

As others have said, they may be called different things. But don't skimp on Datasheets. 

We have actually opted, with support from Sales, to move away from Datasheets all together. The primary reason being that we are a relatively fast moving company, and in many cases we have products that are engineered on a DevOps cycle, where new features are being released all of the time. For us to make the request to have the collateral updated every week, would be wasting a lot of people's time. Also, it's very common for sales to download a piece of collateral and keep it on their workstation, thus causing them to send something to the customer that could be 6 months to a year out of date. Instead, the one thing for us that is always up to date is the website, so as a company we have agreed that our product pages on our website are far more superior to the datasheets. And for those that want a more technical hands-on dive into the functionality of the product, we have created Technical whitepapers that we, in PMM, can update at a moment's notice when the product changes (these whitepapers are 15+ pages long and are for more of the late-mid to end stage buying cycle). This has been serving us very well, and has freed up a lot of cycles between teams.