Please use the mailing list to ask for support.

http://www.horde.org/mail/ contains a list of all available mailing lists.

Version I'm using is 3.0.1 as stated above. I arrived at this solution 
by a lot of googling and looking over the code. Whether it makes sense 
or not, it works.

That extract is unchanged from 3.0.1 to 3.0.3 (I assume this is what 
you have). There are no changes between these versions of backends.php 
related to hordeauth or anything related. In other words, nothing "on 
paper" to indicate changes to this file's usage that may occur 
(implemented elsewhere in the code) between versions.

If all that's required is an upgrade then great, but I'm not in a 
position to do that on a whim with this server, and nothing in this 
file or elsewhere indicated that that would help; if I'd thought 
otherwise, I'd certainly have tried upgrading before filing this ticket.

I'll now schedule the upgrade as soon as possible to test whether it 
solves it. Am I correct, then, that hordeauth (or whatever now 
performs that function) is now defaulting to supplying just <USERNAME> 
instead of <USERNAME@DOMAIN>? (The link that provided the clue to my 
fix indicated that this was its effect, with the default value being 
'full' which appends the domain to the username.)

I don't know which version of Ingo you're using, but in the latest 
stable version from pear, I can't find any references to 'hordeauth', 
so the above doesn't make sense to me. Admittedly, older versions did 
use this, but this is no longer the case per the comments in 
'ingo/config/backends.php':

  *   NOTE: By default, the transport driver will use Horde credentials to
  *         authenticate to the backend. If a different username/password is
  *         needed, use the 'transport_auth' hook (see hooks.php) to define
  *         these values.
The below are the contents of my 'ingo/config/backends.local.php', 
which is working fine with Dovecot 2.1:

<?php
$backends['imap']['disabled'] = true;
$backends['sieve']['disabled'] = false;
$backends['sieve']['params']['usetls'] = false;
$backends['sieve']['scriptparams']['utf8'] = true;

Solution: additional directive in backends.local.php

$backends['sieve']['hordeauth'] = true;

If I understand correctly the *current* state of play (based on the 
sources, some admittedly probably outdated, that I've found while 
researching this), and based on what I've observed above, it appears 
that either the hordeauth param or a case-suitable entry in 
hooks.local.php is *required* or timsieved driver will do nothing at 
all.

Fair enough, perhaps mine is a corner case (seems a bit unlikely, 
mind) but this requirement, or at the very least the existence of the 
hordeauth parameter, should be documented in the header notes of 
backends.php. In my case it would have saved a couple of days of 
wild-goose-chasing at any rate.

I haven't attempted this setup before, so I don't know how far back 
the issue goes. Lots online about setups up to mid-2011 or so, 
involving H3/4 and dovecot-1x, but nothing for H5 / dovecot-2.x (and 
no documentation that I can find).

/ingo/conf/backends.local.php as follows:

$backends['imap']['disabled'] = true;
$backends['sieve']['disabled'] = false;

$backends['sieve']['params']['usetls'] = false;
$backends['sieve']['params']['debug'] = true;
$backends['sieve']['scriptparams']['utf8'] = true;

I have logging at DEBUG and see nothing to indicate an attempt to 
contact the managesieve process, likewise in the dovecot log (whereas 
it's evident when I probe it with netcat).

In Configuration > Ingo, I've tried both Preferences and SQL storage 
backends: no difference. Also I've tried setting the configs above 
directly in backends.php, still no joy.

The auth parameter in Horde config is set to use Imp for login (which 
in turn uses IMAP login to the same dovecot instance). Everything else 
I can think of is pretty standard. On Gentoo but using the pear 
install method (clean H5 install).

Happy to provide whatever further info requested, just ask.