What are the SOLID principles in respect to C#?
SOLID is an acronym that represents five principles of object-oriented programming and design, aimed to make software more maintainable and scalable. These principles are:

Single Responsibility Principle (SRP): A class should have only one reason to change, meaning it should have only one responsibility.

Open/Closed Principle (OCP): Software entities should be open for extension but closed for modification.

Liskov Substitution Principle (LSP): Subtypes must be substitutable for their base types.

Interface Segregation Principle (ISP): Make fine-grained interfaces that are client-specific.

Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules. Both should depend on abstractions.

These principles can be applied to C# code to improve its design and maintainability.
This seems like a method for overengineering that treats every problem as a class design issue, every class as a contractual interface, and prioritises grand designs, verbosity, fragmentation and the proliferation of new nouns, over organic growth, readability and common sense.

I can see the value of rigour in API design at system boundaries, and LSP seems like a fancy name for don't do weird things but does the rest of it it have any merit outside of class-maximalist languages like Java, C# and C++?
Great question!

The answer is yes, but with some practical caveats.

It's always important to remember that these frameworks exist to make codebases more understandable, flexible, and maintainable. This makes it easier for people working on the code to do their work. It has maximum benefits for people who did not write the original code and are contributing to the codebase. So the principles apply generally to most languages, even those without object-oriented features, especially those that allow code organisation into modules, packages, files, etc. Consequently, one has to pick and choose aspects of the SOLID principles that apply to them. So a common sense approach to how these principles are applied is important.

Practical implementation of SOLID principles requires additional effort initially but pays dividends as the team and features in the code base grow. Therefore, these principles benefit larger teams and projects regardless of language. Over-engineering happens if the dividends of applying these principles within a set time don't occur due to the codebase or the team not growing in that time. For example, if only one person works on a small codebase that is unlikely to grow, using SOLID principles strictly may lead to over-engineering. 

The caveats to this approach involve deciding on how much of the design principles are implemented on new code vs how much they are applied to code via future refactoring. In many practical cases, it is better to implement some of the design decisions as the need arises via a code refactoring process. This approach helps balance the need to implement the principles as required and write new code without stringent constraints.