does writing scripts in C# compromise the capabilities of the engine's performance significantly?
People place far more emphasis on language choice than they ought. You can write bad code or good code in any language. Some languages are more naturally a better fit to certain problems than other languages, but you can still get great performance out of mainstream languages if you try.
There are portions of games that need to have good performance, especially on games with a soft realtime requirement of 10ms or faster per screen.
While the game engine code may have strong performance requirements, usually the gameplay scripts have minimal concern over performance. You've got tens of millions of CPU cycles every frame, you can use nearly any language to get enough work done to run gameplay scripts.
Two examples: Back in my college days two decades ago we were on 300 MHz machines and were observing the direction of a pointing hand in front of contrasting backgrounds: that's doing camera-based gesture recognition (generally considered a slow processing task) doing it in Java (often called a slow language), and a simple, naive implementation was taking only a few hundred thousand cycles, leaving about 1.5 million free cycles per frame for other work. On several programs we've written simple "just enough to get the thing working" scripting systems, all interpreted, and a few people were worried they would be too slow. They weren't super speedy, but the were never actual bottlenecks. Processing was taking place outside of critical paths and never blocked or notably impacted performance.
Performance problems are seldom where programmers initially think they are. Language choice itself is generally not the cause of performance problems. Bad algorithm selection, useless memory allocations, blocking operations, and stupid simple errors are the typical source of issues. But for deciding between C++, Java, C#, Lua, even JavaScript, all of them are viable languages in today's games.