Ultimately, it comes down to who will maintain this. If you're hoping to pass off ownership of this and let someone else maintain it, go for the longer but simpler approach.
If it's something that you'll be in charge of forever, get as clever as you can :)
Remember the words of Kernighan:
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
I don't think it really matters who is going to maintain the code in the future. Even if you think you're going to be the sole person maintaining the code for a long time, why is being "as clever as you can" a win? 5 years down the line in a large system, you might not remember the reasoning behind your earlier cleverness anyway.
The complexity in a program should come from the problem it is attempting to solve, not the trickiness of the implementation. I personally prefer code that is as simple as possible (but no simpler, to coin a phrase) -- there are enough things that can go wrong in a complex software system without adding overly-clever code into the picture.
I think one of the primary guiding principles of software design ought to be simplicity: strive to make everything as simple as possible, except where other requirements like efficiency, robustness, functionality, or portability supersede.
Yes, but beware: Additional smartness does not always stick.
And smartness can be highly conditional. Clever code is often written by calm and well-rested people, but its showstopping bugs are often fixed at 3am by panicked people who are losing thousands of dollars per second.
If it's something that you'll be in charge of forever, get as clever as you can :)
Remember the words of Kernighan: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."