Is this a fundamental rule? I thought it was something highly valued by python culture but not by, say, ruby on rails.
One example is overriding an association proxy to have other side effects. Sure it makes for a few very sort lines of code to cause whatever those effects are, but unless someone has read the implementation of the code that behavior becomes completely opaque.
Similarly, acts_as_foo plugins that add implicit behavior everywhere.
The core idea was clever at the time -- that one could do better domain modeling than a few sql statements in a file by using AR and callbacks, but after the app gets a bit complex the domain model classes typically become very tightly coupled and much logic has been flushed away into implicit behaviors to make the remaining code halfway readable.
I have yet to see a Rails app that can stick with the basic structure with over 20 models and still feel remotely well engineered.
app.php
<?php
// logic and state here
include 'some_other.php' // modifies or adds state in unknown ways
// more logic
$some_variable = 3; // does the include below depend on this? who knows.
include 'yet_another.php' // expects state, who knows what
// also modifies state
echo $state; // not sure if we can remove/replace any of those includes and this will be as expected.
?>
The same can be found in Rails in partials.
Also, in Rails, helpers are essentially crippled presenters that have access to lots of effectively global state and thus cannot be reused.
Of course, not all problems have default solutions and those should usually not have default behaviours.
To be honest, I'd rather state the rule as following when designing an API: "Do the obvious thing". Sometimes that will involve explicitness, and sometimes it will involve implicitness, but almost always it will be a mixture where some aspects are explicit and some things are implicit. The hard part is figuring out what should be which.
TLDR: with RoR, things like `[1,2,3].third` or `foo.present?` is highly encouraged.