What's the point of Mono on Windows
There are a couple of features Mono has that .NET doesn't.
Mono is highly modular. You can break it apart in tiny little pieces and only deploy exactly those parts that you need. Don't want System.Xml? Fine, it's gone.
Mono is embeddable. You can host it inside your C/C++ application, to allow users to script it from a safe managed sandboxed environment. The most famous example of this is mod_mono, which hosts Mono inside the Apache webserver, and is how ASP.NET is implemented in Mono, for example. This feature goes great together with the modularization mentioned above.
This has already been mentioned: static linking. Also goes great together with modularization.
Compiler as a Service is another one. Anders Hejlsberg has been talking about it for a long time, and maybe, just maybe it is going to be ready for C# 5.0. Well, Mono already has it, and actually had it for years.
Miguel de Icaza, Mono's Lead Developer also has an initiative that he calls "Embrace and Extend.NET", which extends the CLI in ways not (currently) possible with other CLI implementations (including .NET). So far, Embrace and Extend.NET has three features.
Mono.Simd, which gives safe and controlled access to the SIMD instructions of the underlying CPU (e.g. SSE on Intel or AltiVec on PowerPC). Used for Games and Graphics.
64 Bit array indices, which are allowed by the ECMA specification, but Mono is the only VM that actually provides them. Used in supercomputing.
And most recently, continuations. This is actually the first time that Mono strays outside the realm of the specification: long array indices are perfectly valid as per the spec, and Mono.Simd also works on every CLI compliant implementation (albeit very S-L-O-W), but Mono.Tasklet needs special support from the VM that is not part of either CLI or .NET. This is used for game logic and e.g. in Second Life.
Because Mono Doesn't implement .Net 100% the same as the MS .Net Framework, it's good that you can test out on Mono without having to run on Linux. Also Mono has bindings to make forms with GTK which MS doesn't support.
Mono does some things the .Net doesn't.
For example, mono supports static linking so you can build, compile, and distribute your app without requiring a separate run-time installer. If you built an app to rely on mono to be cross-platform, there are some differences from .Net and so sticking with mono on Windows is a greater guarantee of compatibility.
.Net does some things that mono doesn't.
There are a few places in the BCL that are not yet ported for mono, such as WPF and Winforms, among others.
If you want an app that will also work on mac/linux you probably want to develop for mono first, even if you're doing the most of the work on windows.
Note: all of this pre-dates .Net Core/Standard.