Log file rotation is not only related to technical issues with the file itself. It's also related with operational considerations, like:

• being able to incrementally backup the logs
• reducing to a decent minimum the risk of loss of events logged (open files in a hard system crash can be at risk)
• passing log files to a secure archival for preventing tampering, or to a SIEM system for threat detection.

While it is less problematic nowadays to deal with large files, large files (constantly reopened) negatively affect these needs.

If you only log debugging information, you can ignore these constraints. but for a long living large system , especially with binary logs, the question is not IF you'll face a byte corruption but WHEN.

Log file rotation is not only related to technical issues with the file itself. It's also related with operational considerations, like:

• being able to incrementally backup the logs (especially in case of transaction logs)
• reducing to a decent minimum the risk of loss of events logged   (open files during a hard system crash can be at risk)
• passing log files to a secure archival for preventing tampering, or to a SIEM system for threat detection.

While it is less problematic nowadays to deal with large files, large files (constantly reopened) negatively affect these needs.

If you only log debugging information, you can ignore these constraints. but for a long living large system , especially with binary logs, the question is not IF you'll face a byte corruption but WHEN.