If you are writing functions in Bash, your task is probably sufficiently complex that it would benefit from being written in a language other than Bash.
Bash functions are very useful when you want to manipulate the state of the shell in some way. That is, you write a function for it and stick that function in your .bash_profile. (Unless ofc an alias would be able to perform the job in which case one should just make an alias instead.)
Beyond that, I have been in many situations where standalone shell scripts make the most sense for a task and in which case bash functions have helped me organize the code such that it is both more readable and also so that I don't have to repeat sections of code multiple times within a single script.
It all comes down to personal experience and preference, I think.
I wrote sh for this very reason http://amoffat.github.io/sh/ This lets you use a programming language, instead of a shell language, to solve programming tasks.
Actually, this is exactly the sort of guide I've been meaning to read, since I'm inclined to take the opposite view.
Too often, I think, my task is probably sufficiently simple that it could be a nice portable obviously-a-script Bash script rather than Python/whatever.
Agreed. Bash (and similar scripts) are particularly useful in tasks involving filesystem and process management, where they offer capabilities that are more complicated in other languages. Functions are a helpful way to organize your use of those capabilities.
Zsh has quite a nice option "auto_cd". If the first word you type doesn't resolve to a command, it tries to change the current working directory to it instead. So just typing ~ will get you to $HOME, and .. will take you up one.
I love this option. I type "/tmp" when I'm about to create some short-lived scratch files. Those saying "you can just alias that" are missing the point. Where do you stop with the aliases?
Yes. Although you get it for free with Zsh where it works with any directory you type. Not just the ones you think to make an alias for beforehand. :-)
Even if that is true, it doesn't mean you should not cleanup and organize the bash you have "today" and will port "tomorrow". In the meantime your bash will be better organized and more maintainable.
About 7 years ago I had a job where we supported almost every Unix all the way back to AT&T SVR3 (including OpenServer, UnixWare, HP-UX, AIX, Linux, OSF/1). With the exception of SVR3 every single one had binary packages for Perl 5.
Your point is valid, that bash should be avoided as processes become increasingly complex. But there is still room for bash. How much room depends on what you are trying to do.
Beyond that, I have been in many situations where standalone shell scripts make the most sense for a task and in which case bash functions have helped me organize the code such that it is both more readable and also so that I don't have to repeat sections of code multiple times within a single script.
It all comes down to personal experience and preference, I think.