A few issues
Deleting, updating rows, record locking
You can not delete more than 100k rows In a single Apex transaction, but wait it gets worse.
This includes child rows that have been both deleted and removed from the recycle bin.
You can instead delete all the lines first ensuring any lookups are nulled as you do, this does mean an update is needed before the delete which halves the allowed dml rows and if you want to empty them from the recycle bin you are looking at a third.
Alternatively you can wait for the child records to be "hard deleted" by salesforce a process which can take a few days to kick in. I think you can also raise a case to get it done.
I have seen a parent record in a MD relationship being unable to be deleted for almost a week with people very confused as it seemed there were no related records left.
We are obviously limited to 10k dml rows in a single Apex transaction so if you were wanting to have some logic done on the children in MD relationship any more than that and you have to start looking at splitting writes across asynchronous processes, but you are trading off transactional integrity. Which may not be an issue in your case.
This one might not be that useful but I find it interesting anyway.
If you have lookups on those child lines that use the restrict delete (Don’t allow deletion of the lookup record that’s part of a lookup relationship) then SF is going to lock those related records when you create or update your child lines.
This can mean that if you were wanting to perform parallel writes on rows that lookup to the same record there is a good chance you are going to hit a locking contention.
So if you are going to be dealing with volume
1) Don't set lookups to required (so they can be nulled)
2) Do not use (Don’t allow deletion of the lookup record that’s part of a lookup relationship) behaviour if you are wanting to support parallelisation.
3) If you were not after the sharing inheritance I would even go so far as to advise against MD if you are looking at a hierarchy of hundred of thousands to millions of rows. This is because of the performance cost at those volumes, I have even maintained my own rollups in the past.