Reuse what you can.
A lot is different between Drupal 7 and 10, with the introduction of Composer, object-orientated code, Symfony components and other third-party libraries, to name a few things.
But, when upgrading a project, the business logic may not need to change.
How it integrates with the new version of Drupal may change - it may use a different module, such as Paragraphs instead of Field Collection, or be within a Controller or Service class instead of a Drupal "hook", but if the majority of the logic can remain the same, it might as well be reused instead of written from scratch.
Presumably, it works as it does in Drupal 7, which may not be the case after it's been rewritten, as bugs and issues may have been introduced.
This is the approach I took when migrating the Override Node Options module to Drupal 8. I picked a test, migrated it from SimpleTest (Drupal 7) to PHPUnit (Drupal 8), ported enough code to make it pass, and moved to the next test.
Most custom applications, though, tend to be rewritten and the old business logic discarded.
Here's the thing
If it works, why rewrite it?
Migrate what you can and only rewrite what you need.
As someone who works on fixed-price projects and includes a bug-free guarantee, it's in my interests to deliver working and stable software as soon as possible, which is also in my client's interests as they get their new software sooner and not from a drawn-out process where everything is re-done from scratch.
- Oliver
P.S. Are you stuck on Drupal 7? Purchase a Drupal upgrade consulting call or upgrade roadmap and I'll help you on your way to Drupal 10.
