Because the myriad ways public people interact with your code through HTTP and routes starts to rival the complexity of getting crypto code right, with a lot of the same sorts of downsides (which is to say problems often lead to security issues, and very few people are capable of reasoning about all the implications of the decisions made). I would suggest someone not roll their own framework (which is essentially creating a framework of their own at some level) for the same reasons I would suggest someone not roll their own crypto. The upside is relatively minuscule compared to the downsides, IMO.

> Nobody sees any other kind of application written by a previous programmer and cries "oh no! I am entirely at the mercy of this previous programmer! If only they had used one of the dozen competing frameworks this tragedy could have been avoided.".

Yes, they do. If you came upon someone's custom HTTP client, I imagine your response would be something along those lines. If not lamenting that you're at their mercy, at least cursing them for imposing a requirement of some level of strength that you use what is very likely to be a substandard implementation of what you can find freely available. So, you either replace it with something less likely to cause the odd problem later (and deal with all the testing to make sure you didn't introduce a bug, and you probably did) or deal with those odd problems ("what do you mean we aren't conforming to TLS correctly? Why haven't we seen this until now?").