I use it for greek letters mostly, when it suits the math. However, I have mixed feelings about it and will probably do an ASCII only rewrite soon.
Note that we already had long threads about the opinions of you and others on this matter; see e.g. Syntax: Escape hatch for unicode haters or Unicode: a bad idea, in general … it’s probably not productive to re-hash it again.
TLDR: Some people like using Unicode identifiers, primarily to make the code closer to mathematical notations in domains where that is very standardized, and others do not. There are various ways to type them, from editor tab completion (\foo<TAB>) to OS shortcuts (e.g. option-x for ≈ on Macs) and language input modes (e.g. switching to Greek input mode) to custom keyboard layouts. For most packages, however, people tend to avoid requiring non-ASCII characters to access an API, either by keeping the external APIs ASCII-only or by providing ASCII equivalents to Unicode APIs (e.g. the way you can use the non-infix xor(a,b) instead of the infix a ⊻ b). Across the Julia ecosystem, you’ll find varying degrees of Unicode usage in code, but it mostly seems concentrated in math-heavy applications.
I use it a lot and enjoy it. Yes, it’s clumsy to write, but this makes math code so much more readable.
And a loop written as
for xᵢ∈x
...
end
is too cool for words. In fact, I wish I could write it as
∀ xᵢ∈x
...
end
Thumbs up! 
My package WringTwistree (GitHub - phma/WringTwistree.jl: Whole-message cipher and tree hash, Julia implementation · GitHub) has constants called ℯ⁴_2adic and ℯ⁴_base2 and a singleton structure member яхид::Яхид. I’ve written (and hopefully will resume working on) a network program in which nodes send messages to each other in which the opcodes are Greek and Russian words; to test it, I used several Unicode characters including a Cyrillic multiocular O and a Gothic hwair.
I have four keyboard layouts (Latin, Greek, Hebrew, and Cyrillic) to choose from, with the Latin keyboard having the compose key enabled, so I can type ⁴ with three keystrokes and яхид by switching layouts, but ℯ I typed in the REPL with the backslash, then copy-pasted into Kate, and the Cyrillic and Gothic letters I copied from Wiktionary.
A complete offtopic, but I found it interesting and crazy in many respects.
Cyrillic ocular O variants were apparently used only in some Old Church Slavonic manuscripts and for only one word (root) - oko (Cyrillic око), meaning eye and surely related to Latin oculus or Italian occhio. Monocular o (Ꙩ) resembles an eye. Now, eyes mostly come in pairs, therefore in even rarer manuscripts there are two different o glyph forms for the plural word eyes.
The multiocular O is a unique glyph occurring exactly once in just a single 15th-century manuscript, as many-eyed angels are not that common. It has been found worth its own Unicode representation, which I find very laudable and inclusive! It is just a pity that we (i.e., the mathematical folks) do not get superscript and subscript glyphs for all 26 English letters.
Yes, that is another crazy aspect of it: things long dead, buried, and forgotten suddenly start an eventful afterlife of their own.
I also like the possibility to use ω = 1 instead of omega = 1, but there are also some challenges associated with the use of Unicode symbols:
julia> a = 1
1
julia> а = 2
2
julia> a
1
and
julia> a + а == 2a
false
What is the challenge of not using in your code those Cyrillic letters that cannot be easily distinguished from Latin ones?
The similar look of ASCII chars I, l, and 1 in many fonts - that is really bad.
I think these ambiguities are caught by the linter in VS Code?
I really like Unicode support, and I’m a fan of providing an API with both (1) a Unicode and (2) an ASCII interface for the keyword arguments, for example by defining both σQ=default_val and sigmaQ=σQ for the standard deviation. This is also handy for common notations like Δ for the variation and x̂ for state observers.
Mind you of the trap of that kwargs multi-options. The use of each variation recompiles the function, and for big/complex functions this is not a minor issue. Even calling the kwargs with a different order, recompiles.
I don’t use fancy characters, but the simplest unicode characters. Reason: LaTeX has relatively limited support for unicode in program listings “out of the box”. Even with the Julia Mono fonts (it is not straightforward to set it up).
Yes, to have Julia code listings in a LaTeX document where the Julia code uses a non-ASCII characters, I end up using a bunch of \DeclareUnicodeCharacter statements, e.g.:
\usepackage{upgreek}
\usepackage[utf8]{inputenc}
\DeclareUnicodeCharacter{03B5}{$\upvarepsilon$}
\DeclareUnicodeCharacter{03B4}{$\updelta$}
\DeclareUnicodeCharacter{0394}{$\Updelta$}
\DeclareUnicodeCharacter{03C9}{$\upomega$}
\DeclareUnicodeCharacter{2032}{$^\prime$}
\DeclareUnicodeCharacter{2248}{$\approx$}
\DeclareUnicodeCharacter{221A}{$\surd$}
\DeclareUnicodeCharacter{03F5}{$\upepsilon$}
\DeclareUnicodeCharacter{2207}{$\nabla$}
\DeclareUnicodeCharacter{03B1}{$\upalpha$}
\DeclareUnicodeCharacter{22C5}{$\cdot$}
\DeclareUnicodeCharacter{2080}{$_0$}
\DeclareUnicodeCharacter{2081}{$_1$}
\DeclareUnicodeCharacter{2082}{$_2$}
\DeclareUnicodeCharacter{2099}{$_{\mathrm{n}}$}
\DeclareUnicodeCharacter{2297}{$\otimes$}
\DeclareUnicodeCharacter{2113}{$\ell$}
…but this doesn’t work for combining characters, I think? Not sure if there is an easier way or an existing tool to automate this?
(The above example was for course notes where I wanted the Julia code listings to mirror the notation in the text.)
I use LyX, and managed to get a reasonable set-up. I do need to declare a few unicode characters, I think, but not too bad. Another thing is that I need to specify color coding for Julia functions, and new functions I create.
One problem is that if the unicode character is the first character on a line, things don’t work. So I need to insert some space or something. I should check to see if there is a zero space character.
I use the mathcal caracters for all parametric types
I use Unicode symbols extensively in PSSFSS.jl, where, as one example, it is very nice for microwave engineers to be able to use standard symbols to represent relative permittivity, permeability, loss tangent, etc. for a dielectric layer. For example:
julia> using PSSFSS
julia> Layer(width = 2mm, ϵᵣ = 2.2, tanδ = 0.001)
Layer: width=2 mm, ϵᵣ=2.2, tanδ=0.001, μᵣ=1.0, mtanδ=0.0, 0 modes
The user can also choose to use ASCII equivalents to avoid typing the symbols:
julia> Layer(width = 2mm, epsr = 2.2, tandel = 0.001)
Layer: width=2 mm, ϵᵣ=2.2, tanδ=0.001, μᵣ=1.0, mtanδ=0.0, 0 modes
Note that in either case, the Layer object is always mirrored to the REPL using these standard math symbols to display its electrical properties.