To use a tool effectively you need to understand how it works, potential quirks, pitfalls etc. as well as the basic more straightforward operations.
A tool as complex as the FPC compiler is not going to be mastered overnight. The official documentation (FPLanguageRef, FPProgrammer's Guide, FPUser's Guide) runs to over 520 pages already.
As used in Lazarus to program GUI apps, various more complex program features are called into play, including the unpredictability of the event-driven paradigm in which user-induced variation at runtime is a designed-in feature, not a bug.
As wp indicated, a straightforward if ... then ... else construct will ensure that the DialogDate.Date property is set before the user sees the dialog, that the dialog is subsequently called (DialogDate.Execute) by the user, and that the resulting value of DialogDate.Date is only read after that, at runtime, after the user has chosen a date.
Since the OP introduced a different program construct than a simple if/then/else (a function with three parameters) he is then at the mercy of how that function is implemented in detail by the compiler. "The devil is in the detail".
It is not that the compiler has changed any logic. It is that we as programmers often fail to understand the detailed logic of complex constructs that we write. Hopefully we learn from finding that a particular construct (perfectly logical to the compiler) does not have the effect we intended. Occasionally we uncover a compiler bug. But usually the shortcoming in faulty code results from our own inability to see that there is a difference between the algorithm we expected our code would implement and what we actually told the compiler to do.