Object constructors are that way because just about the only reason to really have a (non static) class is because you have state with invariants that the methods guarantee, and the constructor is just a method (with some complex compiler rules, but a method nonetheless) that ensures that's true from the get go.
Even for a POCO this holds true if the class is designed to be immutable, the constructor is simply maintaining the invariant that, post construction the outside world will only ever see the object in that form.
Since f# values interop with other .Net highly, and has no issues with someone using mutability if they so desire, it just uses .Net arrays.
The 'create an array' aspect in f# is inherently therefore going to make you sacrifice immutability in some way unless it stops you treating .Net arrays as such, forcing the construction of them on the basis of ensuring their state, when you can just mutate them straight after seems a bit pointless. What many simple functional languages which value immutability supply for linear data structures instead is either linked lists, or things that look like arrays w.r.t random indexed access, but any attempt to modify one in fact creates a whole new array, with that modification applied. Given f#'s decision to use .Net arrays it is better (IMO) to keep the mutability a facet of the array, rather than force any types you want to use within an array to sacrifice immutability (or some other invariant).
One could of course define a language which specified that, on constructing an array, you were obliged to supply code to 'fill in' all of the elements, and only made the array available to you once that code had run, it could then not be modified further (Haskell has such functionality). You can layer such a thing in f# with a library (if it wants to be fast it will likely need to *use* a mutable array behind the scenes) however, that's not how much of the world MS is targeting with f# works if they are trying to use arrays, so why bother not allowing their 'direct' use in a language where you're already okay with people mutating state (even if you try to make it easy to not do so).
As far as non null by default goes, in f# Options
can apply to any type, so you can declare an array of them instead. Then you make the 'not defined yet' part something the type system enforces, rather than an ever present hidden pit. That to me is the benefit of non null by default, forcing you to pay for allowing nulls (and giving you compiler help), but only where you need to.
This is, incidentally, not saying f# is better. Just a postulate as to why it's done that way (and why I'm glad it is, for my needs).
1. Multithreaded concerns aside
2. On construction of the contents, they're .Net arrays so of course they're mutable after the event anyway!
3. Here's *not* simple