See details in embedded doc, but briefly:
When you have a text column that you’re sorting alphabetically, cells in this column that have something that looks like a date anywhere in their text (e.g. “Consulting session Mar 3”) will be mis-parsed as numbers and floated up to the top.
LOL indeed!
I hope bugs like this eventually start an internal conversation about whether “duck typing” and trying to be smarter than potential customers of the system is actually a blessing or an evil. As a product developer/designer I know that this is a very tough problem to solve for. When I was developing three.do I was asking myself this question every time I made a design choice: do I want to assume I’m smarter than my user and try to guess what they’ve wanted to achieve there, or do I assume the user knows what they want to achieve and take their input at face value.
I understand why Coda wanted to have this logic in place: to behave in an expected way for people clueless about data types who’d just enter a date-like text value and expect it to behave as a date. I’m not entirely sure if it’s a good practice because I think it encourages ignorance. I’m sure though that the type guessing implementation is definitely flawed 
P.S. @Nick_HE as a workaround, make a column [Text sorted alphabetically].ToText() and sort on that one. ToText() would extract the text input from any type value, strip rich text metadata if present, and return a simple text value that one can alphabetically sort on.
I think you missed the Workaround tab 
But yeah I was surprised to find that dates in the middle or end of the string were parsed as dates - would have expected only pure date strings would be date parsed (a pure date string seems like a clearer indication of user intent). But I expect it’s less a design choice, more a bug arising from a date parser that’s a bit more over-eager than planned.
This is a long-standing bug though, I think I initially reported a year or two ago, so it might not be a trivial fix.
I have a feeling they were trying to include cases where e.g. a weekday name would come before the date, e.g. values like Monday, Jun 23 2020, and went a bit too eager on the matcher 
Maybe they were trying to account for different locales, long and short weekday names etc.
And yeah, I didn’t see the pages panel in the embed above