There's a lot of tools that exist to make what developers to easier to do. If it's something we do a lot, we tend to find ways to have something do it for us.
I've done it. I'll probably do it again. I built a little tool to automate the generation of Android Services based off JSON because I spent so much time copy/pasting existing services and editing them into the new serevice. Copy and Paste means you're missing an abstraction - I couldn't find it, so I built a tool to deal with it.

We find challenges and difficulties accomplishing what we want to do, so we find things we can do to reduce that pain, to simplify the process. It's one of the things I really enjoy about being a developer - I can simplify things I want to do.

The downside of the things that get built, is they get built for the way that developers write code and that's very often not inline with the technical practices. These tools promote writing code in the fashion they're built to simplify. I find that they make it very hard to write good object oriented code. It's simpler to write (not maintain) bad OO code, especially with these tools.

Language Features

C# is the language I've used the most in my career and I like to see what upcoming features are.
Before my adoption of the technical practice, many of these langauge features sounded like FANTASTIC things! Many of them are what made me long for C# when I was developing on Android.
The biggest of these, Properties. Writing Getter/Setter methods in Java was such a pain when C# gave it to me so easy.

C#'s simplicity of creating Getters/Setters as Properties makes it easy to expose data. This violation of encapsulation (getter/setter isn't encapsulation) makes it easy to do. It's easier to do the things developers do, even if it makes the code harder to maintain.

Not all language features are bad - I love the async/await functionality.

One that I thought was AWESOME before the technical practices is the Deconstruct functionality.

This features uses tuples to allow returning multiple values.

 public static void Main()
{
   var result = QueryCityData("New York City");

   var city = result.Item1;
   var pop = result.Item2;
   var size = result.Item3;

   // Do something with the data.
}

private static (string, int, double) QueryCityData(string name)
{
  if (name == "New York City")
     return (name, 8175133, 468.48);

  return ("", 0, 0);
}

Especially with the introduction of Inferred tuple element names

 public static void Main()
{
   var result = QueryCityData("New York City");

   var city = result.Name;
   var pop = result.Population;
   var size = result.Size;

   // Do something with the data.
}

private static (string, int, double) QueryCityData(string name)
{
  if (name == "New York City")
     return (Name: name, Population: 8175133, Size: 468.48);

  return ("", 0, 0);
}

This is just horrible. It simplifies writing procedural code instead of Object Oriented code. When you return a set of data like Deconstruct allows, you're missing an object. If a method is returning a set of values, they are related; why aren't they represented by an object?

Yes developers write code like this, yes C# is making it easier for developers to write code, even at the cost of maintainability. I like that the language designers care about simplifying the use of the langauge for developers... But...
My opinion of the deconstruct feature changed because it inhibits writing object oriented code. It's literally making it easier to not need objects to represent an 'object'. BLEH.

Another one I'm not a fan of that's coming in C# 8 Default implementations of interface members. I recognize the value for libraries and distributions where the interface is really the unchangable API for the product.
I think it's going to be abused. I think it's going to be used as a way to inherit from multiple "classes".
I got nothing backing this except knowing developers are clever.
An ILogger shouldn't be able to define everything needed for logging. It's going to produce things that should be abstract classes - but because it's an interface - just add some default implementations... Yeah!... twitch

... HOLY SHIT... I thought readonly paramters was coming in C# 8... I didn't realize the in parameter came out in C# 7.2... All my projects are getting updated to .NET Framework 4.7.1.

AWESOME!!!!

So, that's a feature I'm super happy about. I write objects to be as immutable as possible, I think letting the compiler know that the variables are also unchanging will enable optimizations.
It's not huge in most of my code, as I strive to not modify things like that; but having that compiler hint should be interesting.

Summary

The languages we use to write code can significantly impact what we write. Writing good Object Oriented Code requires developer discipline to continue writing code in the highly maintainable fashion.

When we are provided with ways to pump out code faster, we tend to use them. The end result is a detriment to the simplicity of the code base. It becomes more complex because it's not improving the encapsulation of the system.
We want to abstract modules to have a narrow interface; a lot of langauge features work against this simplifying abstraction in the system.