The answer to this depends heavily on your use case.
I no longer own a Raspberry Pi,
but the one I used to have came with 512 MB of RAM.
Conveniently, my NFS server has the same amount.
In addition to NFS, this server (like all my others)
has an m68k cross-compiler that sees regular use via distcc.
It also has an always-on GNU screen session
attached to the serial port of another server.
Let's have a look at vmstat:
$ vmstat | awk '{ printf "%4s %2s %2s\n", $3, $7, $8 }' | tail -n 2
swpd si so
0 0 0
In this case, no value of swappiness is better than any other,
as the system never swaps.
Small, embedded systems often don't even have swap space.
From Memory Management Approach for Swapless Embedded Systems,
a 2005 article in Linux Journal:
The Linux kernel Out of Memory (OOM) killer is not usually invoked
on desktop and server computers, because those environments contain
sufficient resident memory and swap space, making the OOM condition
a rare event. However, swapless embedded systems typically have
little main memory and no swap space. In such systems, there is
usually no need to allocate a big memory space; nevertheless, even
relatively small allocations may eventually trigger the OOM killer.
In systems that take this approach, the same holds:
Since there is no swap space,
swappiness can have no effect on the longevity of your storage.
If you are using your Raspberry Pi more like a desktop system,
perhaps running X and doing gene sequencing in Python
for your biology homework (I've seen it done),
then you might have something to worry about.
Let's find out:
Suppose you run low on memory
and your swappiness is set very high,
to almost exclusively page out program memory
and retain file cache.
Suppose also, for concreteness, that you have a class 8 SDHC card
and that it has a (fairly low) 16-kilobyte block size.
Then you can write 8 MB/s, or 512 blocks per second.
Without wear-leveling, and assuming failure after 100,000 writes,
this leaves you only 195 seconds, or just over three minutes,
before failure.
Of course, this is a worst-case scenario.
With wear-leveling,
the failure-time is closer to 100,000 writes
times the number of unused blocks.
Say you have 1 GB, or 65,536 blocks, available for wear-leveling.
In this case, you get (roughly) 65,536 times this amount of time,
or about 24 years of constant swapping.
Since you probably won't be constantly swapping for 24 years,
this won't likely be the cause of premature flash-demise.
Something much more likely to be a problem is
the logging of access times of files.
Whenever a file is read, its access time is updated
unless the filesystem is mounted with the noatime option.
This requires one block to be written every time a file is read.
Journaling filesystems like ext3 and ext4
write extra data to an on-medium journal upon each write.
Some filesystems (e.g. ext2 or FFS) do not support journaling.
Using these filesystems
(or turning off journaling in others)
definitely improves the longevity of flash media,
but reduces data reliability in case of power loss
or media-removal.
I don't think that system logs will in general
contribute much to the death of flash media,
as the only files in my /var/log
that have changed in the past month
are btmp, wtmp, and lastlog.
