First, interfaces are usually easier dependencies to fill/mock when doing unit testing, because there default behavior is... nothing, so you can be sure you're testing classes in isolation.
Second, when you do need to create a custom mock, you don't need to do anything fancy, you just write a class that inherits the interface. This makes supplying dependencies to your classes easier when testing, and sometimes the mock implementation is the 2nd implementation you're looking for.
Third, if you're just writing a class, right click=>extract interface every time, you're not interpreting the "I" in "SOLID" correctly. Interface segregation implies that interfaces are designed for the CLIENT of the interface, not to match the implementation. There is an important difference in that the former will typically yield more loosely coupled design. It is a very fine line sometimes, but worth keeping an eye on.
Of course, if you're not interested in unit testing, and not interested in SOLID, maintainable, testable code, then yeah... interfaces might not have much practical value to you unless you have multiple implementations at run time.