The cookie path doesn’t provide any security (in most real-world situations).
It is important to understand that the cookie spec is ancient technology. It dates back from the earliest days of the web. The security model of the web has evolved since then, and become more carefully thought-out. The security model for cookies hasn’t evolved correspondingly.
As another example of impedance mismatches between the web’s security model and cookies, the same-origin policy treats
http://www.example.com:80 as a different origin from
http://www.example.com:81, but they are treated as identical for purposes of cookies. You can find more discussion of security oddities with cookies from Michal Zalewski.
http://www.example.com/dogs can read a cookie whose path is
In practice, developers typically avoid these corner cases that are left over from earlier days, or at least avoid relying upon them to provide extra security. For instance, web developers should not rely upon the cookie-path to provide security (at best it reduces the number of cookies sent back, which could perhaps be used to reduce bandwidth in some situations). As another example, sites these days usually avoid serving content from non-standard port numbers, since that situation is another corner case that exposes unexpected semantics.
At this point, the cookie path is mostly a vestigial remnant of earlier days. It doesn’t serve much purpose any longer, as far as I can tell, and if the cookie-path had never been introduced, today you’d probably never notice. But browsers still need to support it, for backwards-compatibility reasons. And so it goes, on the web. It is best to think of the web not as a carefully designed artifact but as something that evolved over time — and as a result, has accumulated now-useless gunk, like our appendix.