I think the problem is that, typically, all the various Price components are not known a priori when Item is first implemented. They become known or realized as more Item subclasses are created. If a software dev group actually knew all of their future requirements before implementing a framework...well, a whole lot of software engineering problems would be mitigated :)
Ok, but it surely can be known (and obviously was due to the get_price() interface stub) that every Item will have a Price, so I stand by my intuition that a Price object could be included in Item.
If Item includes a Price object that has all the possible Price properties, it could be easily modified as specs change.