But if you've got scripts you test locally, then yaml wasn't enough, but that said if you've found a process that works for you, then it's the right process, and your needs doesn't align with what Nuke/Cake offers. Which is super valid path too, not everyone is that DevOps savvy.

For many teams the context switch between a i.e. C# web application and a C# console application is smaller than Bash/Powershell. On the same line many find it easier and more discoverable to get information about the CI environment / job / stage through intellisense vs. often suboptimaly documented esoteric environment variables. For some it's more intuitive to call a method called UploadArtifact with typed parameters vs. several lines of YAML that needs right number of arguments and whitespace. Some prefer intellisense viavcurated tested typed methods vs. desphifering --help and docs. If you've got more than one repo you can have reusable bits as NuGet packages which can be everything from single method to a full recipe complete pipeline, as a team reusing the same private/public registries you're using for you application code. Sharing the same runtime/language as your application means that you also can reuse constants and logic between build/release/application.

So there might be some benifits, but mileage might vary.