It's not always "in your current time zone" - it depends on the "kind" of the DateTime. If you use DateTime.Now you will indeed get a value which is in your current system time zone. And I think you meant either DateTime.UtcNow or DateTimeOffset.UtcTicks rather than DateTime.UtcTicks...there's no such property as DateTime.UtcTicks.
When it comes to using the system time zone, It's not about "those iron age societies" using daylight saving - it's more about DateTime basically always representing some sort of "local" date, either in your local time zone, UTC, or an unspecified time zone. That's a very broken design, but not (IMO) in the way that you claim it to be.
Likewise it's entirely reasonable IMO to ignore "the" Julian/Gregorian shift in 1752, partly as it happened in different years depending on the place(and Sweden is particularly strange in this regard). All kinds of aspects of a date/time become weird if you swtch calendar system - and the DateTime type *only* represents the Gregorian calendar system. (If you give it a different one in the constructor, it effectively translates the value into the Gregorian calendar.) Again, I view that as a broken design - but not because of "the" 1752 shift.
So yes, there are plenty of valid criticisms of .NET's date/time handling, but yours didn't quite hit the mark for me.