No master-detail relationship in which the User or Lead objects are the master?

Well as John Gaughan says, the basic reason is "because Salesforce says so" or perhaps I would phrase as "it's a platform limitation."

Architecturally, it is because there are limitations in the Salesforce platform due to a Salesforce architecture characteristic that could be phrased as "all objects are equal, but some are more equal than others."

Some of these are justifiable from a software design perspective: User in particular could be argued needs to not be just a basic first-class object, since it governs security, licensing, and has special needs (like usernames being globally unique). That doesn't (IMO) justify not being able to have M-D relationships at this point, or why the page layouts of User don't have the flexibility of other objects, but that's what we've got.

Others are because the objects are very old and were hard-coded to behave in certain ways way back in the day and Salesforce hasn't gone back and updated these to the "new world". In this camp, you'll find things like Lead, Campaign, CampaignMember, Attachment, Activity, PriceBook, Product2, [Object]History, Queue, etc. You'll also find weird fields like Opportunity.StageName, Opportunity.CloseDate, CampaignMember.Status, the Integer field type, and the awesome-yet-still-unavailable-to-custom-object polymorphic lookup fields like WhoId and WhatId.

Others are reverse limitations where Salesforce has the privilege of granting "their" objects behaviors that are not extended to the general platform, presumably because it always costs way more to "platformize" the feature. Chatter is a good example, as are platform-level features like portals & communities, groups & profiles, queues, etc.

15 years on, it's pretty easy to look back in hindsight and from the perspective of language/platform development say things like "why is not an SObject simply always an SObject?" or "why is the Salesforce Limits Quick Reference Guide 38 pages long?"

If you were developing a Salesforce-like platform based on what we know Salesforce is today, many of these decisions would probably not have been made. But Salesforce morphed from a fairly straightforward SaaS customer database system into the massive platform it is today over many years, and along the way, many compromises, cost-benefit tradeoffs, customer demands, and difficult/questionable design decisions were in the mix. And many times that results in a platform that isn't as elegant as it could be or has limitations that we (as developers) find frustrating. I'd recommend changing your line of questioning from "why can't I do (X technical thing)" to "how can I solve (X business problem)?" because despite some of the frustrating technical limitations, you can accomplish almost anything on the platform.

TL;DR: because that's the way it is :)