I've been digging around and this is what I've found.
1. According to the POSIX documentation, cron starts crontab tasks in an environment that uses/includes the default ('system') shell /bin/sh. But in raspbian (debian too?) /bin/sh just references /bin/dash - type man sh and you get the dash pages. So commands put in a crontab start in dash.
2. Sure enough, according to man dash, dash does not recognise the (bash) redirection operators &> and &>>. So what did dash make of the &> in 'ls -l &> ./Ten.log'? Like bash, dash recognises a 'control' operator & that puts execution the part of the command line that preceded the & into the background. So I think dash read
and started ls -l, put that process into the background without redirection, then processed the redirection (which created the empty log file).
3. The raspbian documentation I traversed is, in places, incorrect and seemingly inconsistent. For example, man dash ( and man sh) says
dash is the standard command interpreter for the system. […]
The shell is a command that reads lines from either a file or the terminal, interprets them, and generally executes other commands. It is the program that is running when a user logs into the system (although a user can select a different shell with the chsh(1) command). […]
However, by default in raspbian (and debian?) an interactive user logs in and gets bash, not dash.
And I could not find anything in (raspbian) man cron or man crontab that specifies what shell tasks are started in. I needed to go to the POSIX documentation for that.
4. It seems that dash was created because bash was considered too big and too slow, especially at boot time. I can sort-of follow the logic that then led to dash being installed as the default or 'system' shell. But then someone reverted? the default interactive shell to bash, presumably because bash was somehow better for interactive users, without changing the man pages for dash.
Like many a new user of raspbian, I guess, I expected that by default a command line I made up would have the same effect entered interactively or run from my own 'script' (I regard my crontab entry as a 'script'). It seems such a natural thing to do is to try a command line out then put it in a script. At the very least, the little introduction that gets inserted into every new user crontab 'script' by crontab -e should include a warning that crontab tasks may/probably will not be started using the same shell that the user is currently logged-in to. That would have saved me a heap of time!
(Ideally in addition man crontab should contain more comprehensive information about the task starting environment and man sh should not be incorrect as to dash being the shell that a user logs in to.)