Донт агри.

Начнем с того, что выше не так:
То, как подавать требования внутри отдельно взятого UC или US - на практике на выбор автора (на что, кстати, намекает наш недавний опрос в группе). Сценарий внутри UC можно описать как "техническим" языком (например, ответы системы описать в терминах UI и включить туда все мельчайшие шаги алгоритмов системы в ответ на действия пользователя), так и "пользовательским" ("простым языком", описывающим только внешне видимый результат для юзера, а не детальные действия системы), причем последнее даже рекомендуется в большинстве теорий (дальше буду называть это "классиками").

Но: вне зависимости от языка внутри UC, они (UC) РОВНО АНАЛОГИЧНО US сфокусированы на потребностях пользователей - это техники взгляда на систему с позиции того, что пользователи могут сделать с системой и какую свою цель закрыть. В отличие, например, от взгляда со стороны features (которые системоцентричны).

Теперь о действительных ключевых различиях между техниками:

1) UC крупнее. UC описывают обособленную полезную операцию (достаточно обособленную, чтобы о ней можно было сказать "я пошёл в систему ради этой операции - сделал действо - ушёл, оставшись довольным"). Позвонить контакту - UC для мобильного телефона. Выбрать контакт из списка контактов - не UC, потому что только ради этого никто в телефон не пойдёт. Это всего-лишь шаг в рамках какого-то UC. Use case slices (UC 2.0) как подход пытался снять эти ограничения, но не прижился.
US такие ограничения не навязывает. Если что-то можно назвать полезным инкрементом системы, это кандидат в US. И в целом, есть такой посыл, что US нужно распиливать и распиливать, пока в принципе пилится (SPIDR), ибо так с ними удобнее работать в плане трэкинга и контроля в плане девелопмента. Выбрать контакт из списка контактов - вполне себе US, если об этом кусочке можно сказать "Раньше этого не было в системе для звонка, а теперь вот, в рамках очередной итерации, добавляем, делая тем самым процесс звонка более удобным".

2) UC имеет меньше свободы в плане детализации. Если отбросить постулат "Аналитик художник, он может творить с любыми техниками все, что угодно", то "классики" рекомендуют определённый формат для UC: предусловия сценария  -сценарии по шагам - постусловия/результаты.
Для US классики ничего не рекомендуют: хоть пишите сценарии внутри, хоть описывайте критерии приемки (что я вижу и получаю - на это, кстати, упор в рекомендациях большинства "классиков"), хоть куски спецификаций внутрь пихайте, хоть ничего не пишите - оставляйте все на устные беседы.

3) US имеет меньше свободы в плане описания. НЕ детализации, а описания. Для US есть такой параметр, как крайне рекомендуемый user story title/statement/description. As a... I want to.. So that... Попросту говоря, практически все "классики" говорят, что, мол, ни в коем случае не забудьте действующее лицо, операцию и ценность, причём объедините это все в такое вот предложение.
UC тут недалеко ушли (актёров и название UC пропускать также нельзя), однако явную формулировку ценности и такой формат склейки "классики" не навязывают (НО рекомендуют где-то в UC это осмысливать и указывать).

4) Последнее и ключевое отличие. Если судить по большинству "классиков" (и у этого есть практическое логичное обоснование), то UC - это целевое состояние системы, набор требований, досконально описывающий то, как операция работает здесь и сейчас. Позвонить контакту - всегда в вашей спецификации требований будет полностью описывать то, как идёт звонок контакту в текущий момент, на 235-ю итерацию разработки. UC - это база знаний. Если в следующей итерации заказчик захочет изменить UC (добавить шаги, поменять название операции и пр.), то в документации UC АКТУАЛИЗИРУЕТСЯ, т. е. МЕНЯЕТСЯ под стать соответствующим новым требованиям.
US -  это постановка задачи, а не целевое состояние или база знаний. Если вкратце, то это связано с тем, что agile - не о красивой документации, а о том, чтобы успешно сделать систему в моменте.