As others explained, this somewhat quirky condition checks whether yesterday's date CONVERT(date,GETDATE()-1) is between two date fields baslangictarihi and bitistarihi. More importantly, it does so without preventing the server from using any indexes that cover baslangictarihi and bitistarihi.
Indexes are created based on the actual stored values, so applying a function to a field prevents the server from using indexes to speed up searching.
So while baslangictarihi <= GETDATE() can use any indexes that cover that field to limit processing only to the matching table rows, dateadd(d,1,baslangictarihi) <= GETDATE() would have to process all table rows, calculate the result and compare it against GETDATE(). In a large table, this can be very slow.
SQL Server Date quirks
The first part has some quirks too, due to SQL Server's somewhat quirky date support. To be fair all databases and programming languages have quirks when it comes to dates.
GETDATE() returns the legacy datetime type which often behaves as a float, with the integral part an offset from 1899-12-30 (no typo, it really is December 30), and the fractional representing time. That's how dates were stored in Visual Basic in the 1990s and Excel (OADate format)
Since GETDATE() acts as a float, it's possible to subtract days by subtracting integers, so GETDATE()-1 is equivalent to DATEADD('d',GETDATE(),-1).
SQL Server has no interval type, so in some quirky code you'll even see people storing intervals as datetime, eg 0000-00-01 01:00 and adding two dates directly. None of the "new" date types introduced in ... 2005 (datetime2,datetimeoffset,date) allows this.
Finally, convert(date,....) converts datetime to date, a type that only contains a date. Effectively, this truncates the time part returned by GETDATE()
The same expression without quirks would be CONVERT(date,DATEADD(d,-1,GETDATE()))