Though I have to mention that based on my experiance with IPB 3 development and code-reading, I really hate the "unvisible magic methods" (such as get__title) because we should always take a look at the base implementation to find out what they're doing, the method name and so on.
Can you implement an NotImplementedException() and when creating the template in the devleoper center, adding all the required methods that you've described in this blog to the starter template so we won't need to peek in the base class to determine why the template not work?
Even better - in the abstract implementation (Translatable) you can create the required methods as abstract, and developer who don't need them will throw NotImplementedException().
When you'll fire these methods, you can put a try-catch block for NotImplementedException and if this is the thrown exception - you'll display an "This feature is not availalbe" message or such.
I, too, agress that in my opinion IPB 4 should have been builted on PHP 5.4 (not 5.5 because it's still in beta, although the Zend Optimizer+ feature is really shinny and I hreally hopes that IPS will make sure that IPB will be optimized to work with it) because, as you've said - it'll take a lot of time to get into the first stable release of IPB 4 - and IPS releasing a new major version (IPB 3, 4, 5 etc.) every few years. The PHP group, however, got a "rule" which says that in each year - a new minor version will be released (5.4, 5.5, 5.6) and an older version will be declared as EOF - the result will be that when IPB 4 will be released - 5.3 will be in EOF, 5.5 will be the latest stable release and it should serve us for few years without been able to use the latest features of the language (excluding that usage of EOF releases will result in bugs and security issues).
5.4 is not much difference: I do think that you should consider upgrading it.
But as you've done in previous versions of IPB, when adding fallback code for json_encode()/json_decode() for instance - you can do it now for password_hash.
Here is a fallback implementation: https://github.com/ircmaxell/password_compat/blob/master/lib/password.php
Edit: Its true that this approch will require you to include addition libraries, but it has its own pros such as it'll match the latest recommended hashing technique, it includes simplifyed API for programmers and gateway that everyone knows that password hashing/comprasion passing through (so, if for example I'm a new developer / new to IPS Suite, I automaticlly knows which functions I should search for in order to find the hasing algorithm, and even can add hashing for my own addons/hooks without digging in your code to find out how you've done your hasing), this approch enables you to include the "cost" parameter, verify if it was changed, rehash and so on.
I believe that you've done your conclusion, but I do think that you should take these parameters into account ;).