Delphi developers never give proper names to their variables.
Delphi developers never assign a string once to a variable, they always calculate it in several places.
Example of bad code:
temp := IncludeTrailingBackslash( ExtractFilePath( Application.ExeName ) ); // Why not use the name exeDir ?
if FileExists( temp + tf.config' ) then 
//If we have to change the name tf.config to something else, we have to scan all code
// to properly propagate the change. The probability that a coding error will be introduced is large.
conf.LoadFromFile( temp + tf.config' ); // Remember to change this value, too!

Also, why one cannot define a simple utility class containing some methods equivalent to .NET AppDomain.CurrentDomain.Codebase? (maybe there is one, but I don’t know about it; is there a Delphi equivalent of NuGet?)

The main issue is Delphi developers have a certain mindset, that includes the tendency to ignore good coding practices.

The updated code looks better:
appDir := IncludeTrailingBackslash( ExtractFilePath( Application.ExeName ) );
cfgFileFP := appDir + 'tf.Config'; // also, the name 'tf.config' should be defined in a single location!
if FileExists( cfgFileFp ) then
conf.LoadFromFile( cfgFileFp );
Another example:

Result := ( FDayNumbersOld < ( Trunc(Now( )) - Trunc(ADateTime) ) );
When trying to debug the code, it is hard to verify there is a date-time value conversion issue.
Delphi developer enjoy having imbricated try catch sections.
Delphi developers enjoy not managing resources via destructors, they prefer using the finally keyword.
The code is already verbose due to its keywords set, when having more than one level of try..catch.finally imbrication, the resulted
code is extremely hard to visualize.
Delphi developers like having a large number of casts in their code (the conversion operators do not exist).
So the code looks often like
OutputDebugString( PChar( PAnsiString( .... ) ) ) )
OutputDebugString(PChar (Format('Invalid type for xxx  in settings file: %s', [E.Message])));
Delphi developers LOVE placing function calls in another function call, like
DoSomething( Format( ' ...', [ GetValue1, GetVal2 ] ), Format ( '...', [ GetValue3 ] ), IsProcessingEnabled );
The resulted code is hard to visualize and it often looks more complicated than it actually is.
Delphi developers LOVE having global variables of all kind.
If an application tries to have a set of modules, ensuring all global variables are properly initialized and released is a nightmare.