OK, this is an old question but still could benefit from another answer. Try these sample use-cases to help explain some of the value in this command.
Lookup table case-sensitivity issues: If your lookup isn't supporting case_sensitive_match=false (in transforms.conf), you can use eval to set your field-values to match the 'case' of what a Lookup table entries.
Character legibility: Some tables, stats, reports, etc. can cause one to confuse certain number-letter combinations (such as you might see in a host_name). In this case, one might consider using eval with 'upper' to help distinguish the characters displayed.
Better as eye-candy: E.G. "IF", most values in a table may be all UPPER cased, except for one. Now, you have an inconsistent view (..a Sesame Street condition: one of these is not like the other). So, using eval with 'upper', you can now set the last remaining field values to be consistent with the rest of the report. Same goes for using lower in the opposite condition.
.. | eval MyField=upper(MyField)
Business use-case: Your organization may mandate certain 'case' usage in various reports, etc.
Personal preference: You just want to see the other case used.
Sentence Case option: Using an additional PARAM in eval ('substr'), you could make the value proper Sentence Case, based on the pre-existing value and your need(s). Below is an example:
Situation: You are ingesting a log were the status={SomeWord} is being added. After you review the logs in Splunk, you notice the developers accidentally used the wrong-case (let's assume caps lock was on) and you get this, instead: status=eRROR. That looks horrible, here is one way to fix it.
.. | eval status=upper(substr(status,1,1)).lower(substr(status,2))
... View more