I don't think this check on the method used is correct in this situation. As Johan said, its for generating markup and I don't think it should not (need to) be enforced during the submit.
With regards to portlets, yeah: potentially there might be an issue too, at least for JSR-168 (Portlet API 1.0).
The current 1.0 portlet spec doesn't formally support servlet access during processAction (when a form submit is processed), but through the Apache Portals Bridge ServletContext solution it actually is possible to do so and WicketPortlet uses it as such. Now, as a servlet context doesn't formally "exist" in Portlet API 1.0, it really depends on the Portal implementation how/what the getMethod() will return.
Most likely simply the value as provided by the underlying servlet request, as in the case of Jetspeed-2 portal, but other portals might do it differently.
Now, for the imminent Portlet API 2.0 (JSR-286, which finally has been submitted to the JCP for validation), this problem will be solved: as it then formally allows servlet access during processAction and getMethod() will return the original value. So, exactly as the current Apache Portlet Bridge and Jetspeed-2 are doing.
To cut it short, most likely there won't be a problem with portlets and definitely not when using JSR-286.
Still, I don't think this specific use-case (a bug in Safari) warrants such a check which is too strict and beyond the formal requirements in my view.