The traceback points to runtime/lua/editorconfig.lua:210.
That line of code looks like this:

  local path = vim.fs.normalize(vim.api.nvim_buf_get_name(bufnr))

The traceback gives the error message Invalid buffer id: 1 . This makes me think that the function call vim.api.nvim_buf_get_name(bufnr) on that line of code is failing because bufnr == 1 is invalid.

Looking at the code of this vim-symlink plugin, I see that there is a call to Bwipeout or bwipeout:

...
  if exists(':Bwipeout') " vim-bbye
    silent! Bwipeout
  else
    if &diff
      echoerr "symlink.vim: 'moll/vim-bbye' is required in order for this plugin to properly work in diff mode"
      return
    endif
    enew
    bwipeout #
  endif
...

I suspect that the call to Bwipeout is causing bufnr == 1 to be invalid.

After much experimenting, I've found a workaround: Changing the BufRead autocmd in vim-symlink into a BufEnter autocmd. So far I haven't noticed any negative side-effects from making this change. I'll submit a PR.

EDIT:
I've submitted PR #16.

I'm still seeing some issues after changing to BufEnter

  autocmd BufEnter * nested call s:on_buf_read(expand('<afile>'))
  " Works for first file. Subsequent :edit ~/my_symlink gave error:
    " python3-rplugin-host: Async request caused an error:
    " Vim(sign):E158: Invalid buffer name: 4
    " python3-rplugin-host: Async request caused an error:
    " Invalid buffer id: 4

An alternative workaround I've been using is to entirely disable Neovim's EditorConfig integration (see https://neovim.io/doc/user/editorconfig.html#editorconfig), since I use a separate EditorConfig plugin anyways for vim compatibility.