There are certain things that just don't work right when using the Apple provided interpreters for particular languages, even if the versions are right. Though I don't recall anymore what the specific problem was, I recall needing to install a custom build of PHP to get a particular library I depended on to work. I wish I could remember more of the details. The point is that I can understand a modest amount of distrust for the built-ins.

There's also the matter that the internal versions of the interpreters run the risk of becoming dated, staying that way, and perhaps becoming so dated that the needed code can't run without later version of the interpreter than the OS provides. Discovering whether it is "too dated" sounds like a fragile process, you'd have to either parse the interpreter version or make assumptions based on OS version.

The solutions I see available are: to leave it up to the user to figure out if a newer interpreter is needed, or just assume the internal interpreter won't work and build your own that you're much more certain will work. This comes down to a matter of philosophy, where MacPorts says "we'll figure it out", and Homebrew says "we trust you know what you are doing."

I found the Python issue to be a particular pain in the ass, since MacPorts's Python build requires tk, which requires some GUI libraries, which ends up building more or less an entire X11 sub-system on OSX that I will never ever use.

This seems like more of a criticism for the python port maintainer than the entire build system. It might be worth posting a request for Tk support to be made a variant of each of the python ports.