I have a feeling he thinks dev stands for in development (i.e. in progress) packages. It actually means the libraries for linking to a packages, i.e. using the package when you are developing something.
This is an opinion - frequently development libraries, header files, etc. are dependent on kernel versions, glibc, etc. More so than binaries themselves. At the very least, a rolling release will change your kernel and glibc. Which means unless your header packages change in tandem, they might cause incompatibility problems.
It is less of a technical issue and more of a workflow one - would you want to handle the explosion of support requests similar to "I have mysql 5.1 but my PHP client does not connect to the DB.... oh crap, I forgot I have mysql 5.0 headers. heyyy, what gave you the right to upgrade my mysql ?"
If you go with the notion that disk space is cheap (and indeed packaging headers and dev libraries would be not too expensive in terms of disk space ), there is really no real reason to separate them both.
What you are suggesting would be near impossible to have happen without the user manually downloading deb packages, force installing using dpkg, and even then apt would shit itself over conflicting packages and broken dependencies. If someone manages to actually do that... well, they're going to have bigger problems than just "PHP isn't working right."
Rarely do packages need a particular kernel version, just ask anyone using xen or openvz where the kernel is often quite old (2.6.18) and not quite as easily upgradeable. The only time I've known of conflicts arising are when you need to use 3rd party binary drivers, or when an application is using bleeding edge kernel calls which is usually a bug upstream.
You may have a small point with glibc, but I imagine they'll just pin it to a major update every 3 to 6 months and give themselves time to test the heck out of it.