Second this. Most people new to VB.NET these days are transitioning from VBA and would find C# far more difficult. Engineers in my office don't write much production code and therefore get to pick what they want to solve problems. Python is very popular and the .NET people are split in 1/2 between C# and VB.NET. The C# code is usually better as the people that choose it are more advanced programmers, but the VB.NET crew still crank out time saving tools and like it.

>"It is by the way an act of cruelty from Microsoft to only provide office users with a 20 year old language that hasn't been updated since the end of the 90s"

Office has support for multiple languages, not just VBA. The three that spring to mind are JavaScript, M and DAX.

You can't really write UDF in javascript, it's nothing like the VBA integration. (and on a personal note, I still prefer VBA over javascript)

UDFs aren't the only reason VBA is used, though if that's what you're interested in it looks like Microsoft are planning something new in this area:

http://stackoverflow.com/a/40727011

Also, if you don't mind using 3rd party solutions, you've got other options:

http://fcell.io/

http://xlloop.sourceforge.net/

The big difference with VBA and javascript / third party solution is that I can send a xlsm spreadsheet to a colleague or another company and he will be able to run it just as well as me, I don't need to spend the next 5 years doing the support of how to reinstall the addin that is required to make it run.

Yes, that's why I said "if you don't mind using 3rd party solutions". If 3rd party solutions aren't suitable in your workplace (some workplaces would only need the extra features in internal-only documents, meaning the add-in installation could be managed by a single IT department rather than by individual users) then the Microsoft solution that's being planned is more relevant.

Also a somewhat limited version of SQL.